In M5, you are able to control this explicitly, by saying whether you
want the files in your VOB to have Unix (LF) or Windows (CR/LF) line
endings.

Prior to M5 (i.e. beta2 and earlier), things worked cleanly only if your
VOB had Unix (LF) endings, which meant you should use insert_cr mode
when you are on a Windows machine, and you should use transparent mode
when you are on a Unix machine.

Cheers,
Geoff


pravesh wrote:

I have projects in CC which I would like to import and synchronize
with Jazz. The import and synchronization work, however, new blank
lines are interjected with the code is brought over from CC to Jazz.
I've played around with the Text Mode on the CC view, however I
haven't been able to resolve this issue. I created views using
"transparent" and "insert_CR" modes with the same
result.

My Jazz server is a Windows box, I believe the CC respository is also
Windows, but I'm not sure. The RTC client machines are Windows as
well.

Has anyone seen this issue or know the correct setting?

A couple of general reminders:

First, if you are using beta2 Team Concert, the only ClearCase Connector
configuration that "protects" you against the line-ending problems in
beta2 Team Concert is:
- use only VOB's that have unix-style (LF only) line endings
- do not override the default ClearCase Connector internal view-mode
setting (which is insert_cr for the internal view).
- for your own ClearCase views, always use insert_cr mode views on
windows clients, and always use transparent mode views on Unix clients.

Second, the line-ending problems in beta2 Team Concert have been fixed
in the M5 release, so once you upgrade to M5, you have direct control of
the line-ending behavior (and you can use VOB's with either kind of
line-endings).

But now suppose you have been using beta2 ClearCase Connectors in a
non-recommended way, or have been using the wrong kind of view mode for
your own views. How do you clean this up?

One approach is to use your favorite streaming editor (such as the
tr/sed tools on Unix), and strip out those extra CR's.

Another approach is to try to use the Eclipse "File > Convert Line
Delimiters To" operation. I'm not sure how well that works in the
Pravesh's case (where he ended up with double CR's in his files), but I
assume it should work (let me know :-).

Another approach if you like to play games with ClearCase is to set up
two ClearCase views, one with strip_cr mode and the other with insert_cr
mode. Then checkout the files in the insert_cr mode view, and copy over
the files from the strip_cr mode view file onto the corresponding files
in insert_cr mode view. The files in the "strip_cr" mode view will have
one of the CR's stripped off, and when you checkin the file in the
insert_cr mode view, it will strip off the remaining CR.

Then, once you have your files cleaned up (with no CR's in the VOB), use
the "recommended" configuration described above until you upgrade to M5.

Cheers,
Geoff

pravesh wrote:

Geoff,

Here's my setup:
-I'm using a beta2a
-the files in the VOB use Windows (CR/LF) windows (verified by looking
at the text files in a hex editor and seeing '0D 0D 0A') at the end of
every line.
-RTC clients are windows machines.

So it looks as though my lines end with CR/CR/LF. Do you think
strip_CR mode is what I need here?

Comments below:

pravesh wrote:

I can create a new view on the existing stream and set it's Text mode
to Unix. Is this what you mean when you say the VOB must have
unix-style line endings? Or is this a setting on the underlying
stream?

Neither. When I say "the VOB must have unix-style line endings",
I mean that if you went into the VOB itself, you'd find unix-style line
endings in the text data. In particular, it is what you would see in a
"transparent mode" view.

The "text-mode" on the view tells you how the line-endings will be
"adjusted" when a file is extracted from the VOB and when a file is
inserted into the VOB.

The Stream has no effect on the line endings you see.

What view types you use depend on what kind of line-endings you are
maintaining in the VOB, and whether you are using the view on a Unix
client machine or a Windows client machine.

Correction to my previous post:
When I look at the files using a hex editor, here is what I see for
the line terminators for the various modes:
- transparent (unix) mode: '0D 0A'
- insert_CR (dos) mode: '0D 0D 0A'
- strip_CR mode: '0A'

That means that you have Windows style line-endings in the VOB for that
file (transparent mode shows you what line-endings are in the VOB).
Since you have Windows style line-endings in the VOB, there is no "safe"
way of using that VOB with pre-M5 RTC. (i.e. you'll find that certain
Jazz SCM operations like "merge" will insert those extra CR's in the files).

Given that, if I understand what you are saying, the pre M5 RTC is
hardcoded to expect only LF or '0A' as the line terminator. If that
is true, shouldn't simply seting my view's text mode to strip_CR fix
the problem? It doesn't, so I must be misunderstanding you
somewhere.

The problem is that pre-M5 RTC can "change" the text mode of the file as
a side-effect of certain operations (merge, etc.). The only way to
automatically "clean up" those side-effects is the recommended
configuration (which ends up stripping out any CR's inserted by RTC).

I'm reluctant to switch to M5 at this point because it seems like it
has it's own set of issues.

Then you will find that certain SCM operations will insert extra CR's in
your files ... you'll need to use one of the techniques I mentioned in
my previous note to clean them up.

Cheers,
Geoff

Note: If you do want to use beta2 with a VOB with Windows-style line
endings (such as Pravesh has), you will want to:

- Use transparent mode view on windows machine (ClearCase switched to
the term "transparent" mode instead of "unix" mode, because as can be
seen in this case "unix" was a poor name for that text mode)
- Use strip-cr mode view on a Unix machine
- Use the -Dcom.ibm.rational.wvcm.ct.TEXT_MODE=transparent for the RTC
client that you are using to create the ClearCase Workspace (that sets
the mode of the internal view used for synchronization to "transparent").

And as always, this is simpler in M5 (:-).

Cheers,
Geoff

Geoffrey Clemm wrote:

Comments below:

pravesh wrote:

I can create a new view on the existing stream and set it's Text mode
to Unix. Is this what you mean when you say the VOB must have
unix-style line endings? Or is this a setting on the underlying
stream?

Neither. When I say "the VOB must have unix-style line endings",
I mean that if you went into the VOB itself, you'd find unix-style line
endings in the text data. In particular, it is what you would see in a
"transparent mode" view.

The "text-mode" on the view tells you how the line-endings will be
"adjusted" when a file is extracted from the VOB and when a file is
inserted into the VOB.

The Stream has no effect on the line endings you see.

What view types you use depend on what kind of line-endings you are
maintaining in the VOB, and whether you are using the view on a Unix
client machine or a Windows client machine.

Correction to my previous post: When I look at the files using a hex
editor, here is what I see for
the line terminators for the various modes:
- transparent (unix) mode: '0D 0A'
- insert_CR (dos) mode: '0D 0D 0A'
- strip_CR mode: '0A'

That means that you have Windows style line-endings in the VOB for that
file (transparent mode shows you what line-endings are in the VOB).
Since you have Windows style line-endings in the VOB, there is no "safe"
way of using that VOB with pre-M5 RTC. (i.e. you'll find that certain
Jazz SCM operations like "merge" will insert those extra CR's in the
files).

Given that, if I understand what you are saying, the pre M5 RTC is
hardcoded to expect only LF or '0A' as the line terminator. If that
is true, shouldn't simply seting my view's text mode to strip_CR fix
the problem? It doesn't, so I must be misunderstanding you
somewhere.

The problem is that pre-M5 RTC can "change" the text mode of the file as
a side-effect of certain operations (merge, etc.). The only way to
automatically "clean up" those side-effects is the recommended
configuration (which ends up stripping out any CR's inserted by RTC).

I'm reluctant to switch to M5 at this point because it seems like it
has it's own set of issues.

Then you will find that certain SCM operations will insert extra CR's in
your files ... you'll need to use one of the techniques I mentioned in
my previous note to clean them up.

Cheers,
Geoff

It's a commandline option for TeamConcert.exe.

This will let you interoperate with a VOB with Windows-style line
endings with the standard Eclipse editors, but it will not prevent the
problems introduced into your files by the beta2 Jazz SCM Merge ... you
will have to fix those up by hand when they occur (using the techniques
described in the earlier note).

Note that this will also not "fix up" any extra CR's already introduced
into your files ... those also will have to be fixed up by hand. (The
auto-fixup only works in beta2 when your VOB has Unix-style line-endings).

Also note that you will need to "replace" your internal ClearCase view
(the one named "DO_NOT_USE_xxx") used by any existing ClearCase
Workspaces you created earlier. You can do that in the "properties"
page for the ClearCase Workspace (go to the "ClearCase" page).

To verify that you have successfully modified the text-mode of the
internal ClearCase view, just check that the text-mode of the
DO_NOT_USE_xxx view is now "transparent".

Cheers,
Geoff

pravesh wrote:

Geoff,

Thanks again for the explanation. It was very helpful!

Is -Dcom.ibm.rational.wvcm.ct.TEXT_MODE=transparent a commandline
parameter for TeamConcert.exe or do I specify this somewhere else?

Are you saying that the above flag will: a) only fix the "display
problem" in the source code editor, or b) only prevent the
problem from componding itself when the Jazz SCM operations like
"merge" are performed or c) both :)

I tried specifying this on the command line, but it seemed to have no
effect on a) above.