Version Comparison Bug?

( CVSSCC )

Type: Public Status:Closed Created: 24 Feb 04 02:00 Updated: 10 Mar 04 03:00

--> Igor Pushkov (admin) at 10 Mar 04 03:00 writes

We modify the plug-in to not use 'cvs update -p', so problem dissappear in
last version 1.2.040316 (available for download)

--> Igor Pushkov (admin) at 26 Feb 04 02:00 writes

You should understand, that this problem appear only on visual
comparison, and nothing more. Visual comparison needed only for human,
and for me this is not very big issue.
If it is really so critical, afraid that you cannot use CVS NT for
your development team at all.

--> jon (user) at 25 Feb 04 02:00 writes

Thanks for the info.
I am using VS.NET 2003. I produced the file by adding a new
text file to a project, typing the text, saving the file, and committing
it to the repository - all through the IDE.
My mistake. I checked the files that I attached in my email to you.
It seems the attaching process altered the ".HEAD" file.
I repeated the test and looked at the two files with emacs in hexl-mode.
The temporary comparison has an extra "odoa", i.e. a "CrLf".
Unfortunately, this is seen as a show stopper by people in my group
because files are being flagged as different when they aren't.
I can't use the unix_cvs because I need the sspi protocol.
Thanks for your quick response!

--> Igor Pushkov (admin) at 25 Feb 04 02:00 writes

This is really bug, but not cvsproxy. I can repeat if with WinCVS
also, but in the same time all work with unix_cvs.exe (shipped with
plugin). To retrieve version used "cvs update -p" command which
produce this extra CrLf.
I submit this bug to CVSNT:
http://www.cvsnt.org/cgi-bin/bugzilla/show_bug.cgi?id=236
If it will be fixed I will notify you.
However, I really not know how to produce such file using VS
.NET/VB/VS. Probably you use some external editor. Also attached file
have only "Cr" not "CrLf" at the end, what it also abnormal for
Windows. So, I think this is not critical and cannot block your work.

--> jon (user) at 25 Feb 04 02:00 writes

Here is an example. The files are attached.
I added 'TextFile1.txt' to my repository. Note that it does not have a
final CR/LF. I ensure it is in the repository correctly by deleting my
local version
and getting latest. The file that is retrieved matches the original file,
i.e.
does not have a final CR/LF. I then execute a "Compare Versions..." -
the file that is retrieved to my temp directory for comparison is
".HEAD.TextFile1.txt". It INCLUDES a final CR/LF. My project
team uses BeyondCompare as its graphical diff tool. It does a
'Quick Compare' first to tell you if the files differ. It sees them as
different because of the extra CR/LF.
Note that if I then edit 'TextFile1.txt" and add a final CR/LF and
check it in the comparison file in the temp directory matches exactly -
in other words, it does not include an extra CR/LF.

TextFile1.txt .HEAD.TextFile1.txt

--> Igor Pushkov (admin) at 25 Feb 04 02:00 writes

I cannot reproduce this problem based on your description. Could you
please provide more detailed description and/or "bad" file.

--> jon (user) at 24 Feb 04 02:00 writes

I think I have found a bug in the proxy.

I have some files that don't have the end-of-file on a line
of its own. These files are retrieved from the repository
correctly by Visual Studio through the proxy, but when
I do a "Compare Versions..." on one of these files
the comparison file that is placed in the temp directory
has the end-of-file moved to a line of its own. This
causes the diff program we use (BeyondCompare)
to indicate that the files (versions) don't
match. Any workarounds/fixes for this problem?

Rate this ticket:

Not useful at all

Partially useful

Useful

Very useful

Ticket

Version Comparison Bug?