New case insensitive behaviour in CVS 1.11.6 and 1.12.1
Hi, I have been playing around with the new version and noticed a bit of a behaviour change that is causing me some grief and am wondering if this is a real bug or an intended behaviour change. To make a long story short (long version follows), Windows clients can no longer distinguish between an active file and a deleted file where the only difference in the filename is case. This is a change in behaviour from CVS 1.11.5. The long version; use a real operating system (or at least some Unix or Linux variant) to create a test directory and some files: mkdir case cd case touch TESTFILE cvs -d import -mtesting sample VENDOR RELEASE Now (still on a real OS), delete the test file and add a new one with a different case: cvs -d ... co sample cd sample cvs rm -f TESTFILE touch testfile cvs add testfile cvs ci -m"changed case" All is fine and dandy when I try to check out this modified repository on a system with a case-sensitive filesystem, but when I try this on Windows, I get the following: cvs -t -d ... co sample -> main loop with CVSROOT=:pserver:.. -> Connecting to ..:2401 S-> do_module (sample, Updating, , ) S-> do_module (sample, Updating, , ) -> Create_Admin (sample, sample, /temp/cvs/sample, , , 0, 0, 1) -> unlink(sample/CVS/Tag) S-> Create_Admin (., sample, /temp/cvs/sample, HEAD, , 0, 0, 1) S-> Parse_Info (/temp/cvs/CVSROOT/rcsinfo, sample, ALL) S<- Create_Admin S-> fopen(/temp/cvs/CVSROOT/history,a) -> unlink(CVS/Entries.Static) cvs server: Updating sample U sample/TESTFILE -> rename(.new.TESTFILE,TESTFILE) -> Register(TESTFILE, 1.1, Fri May 30 19:32:47 2003, , HEAD ) S-> unlink_file(./CVS/Entries.Static) S-> Reader_Lock(/temp/cvs/sample) S-> RCS_checkout (/temp/cvs/sample/TESTFILE,v, 1.1, HEAD, , (function)) S-> server_register(TESTFILE, 1.1, , , HEAD, , ) S-> Register(TESTFILE, 1.1, , , HEAD ) S-> RCS_checkout (/temp/cvs/sample/TESTFILE,v, 1.1, HEAD, , (function)) S-> server_register(testfile, 1.1, , , HEAD, , ) S-> Register(testfile, 1.1, , , HEAD ) S-> Lock_Cleanup() S-> rename(CVS/Entries.Backup,CVS/Entries) S-> unlink_file(CVS/Entries.Log) S-> rename(CVS/Entries.Backup,CVS/Entries) S-> unlink_file(CVS/Entries.Log) C sample/testfile cvs-1.11.5.exe checkout: move away sample/testfile; it is in the way -> rename(CVS/Entries.Backup,CVS/Entries) -> unlink(CVS/Entries.Log) cvs-1.11.5.exe checkout: dying gasps from .. unexpected -> Lock_Cleanup() The version of the CVS client does not seem to matter and this exact same process works with a CVS 1.11.5 server. Does anyone have any suggestions? I was doing a bit of spelunking in the code and it seem to me that to restore the 1.11.5 behaviour, filesubr.c needs to have ign_case set to 0 in locate_file_in_dir (), ignoring the 'Case' command from the Windows client because even through Windows cannot tell the difference, the server can. However, that is definately not something I want to do as I do not undertsand the internals of CVS well enough to know what side effects that might have. Thanks for any insight or suggestions you can provide. - Rob -- Robert J. Clark Quest Software Software Developer[EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: FW: cvs import & checkout -D date_spec
Chen, Susie writes: > > [1st import] > cvs import -ko -kb -I! There's no point in specifying -k more than once, only the last one is effective. > cvs rtag rtag without -r is almost always a mistake -- you have no idea what revisions you're actually tagging. And without -b you're creating a revision tag, not a branch tag. > cvs checkout -D -r > > The rtag command makes the import available only to the branch. I have no idea what that is supposed to mean. import generally makes the import available on the trunk except for files that have been locally modified. If there are any locally modified files, you need to do a merge to merge the vendor changes into the local changes on the trunk. Perhaps it would help if you explained exactly what it is that you're trying to do. And it really would help to see the *exact* commands you're using, or at least exactly what you're using for . -Larry Jones I'm a genius. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: FW: cvs import & checkout -D date_spec
Actually I posted the question for a colleague. Here is the sequence of
commands he used:
[1st import]
cvs import -ko -kb -I!
cvs rtag
cvs checkout -D -r
The rtag command makes the import available only to the branch. The check
outs are fine at this point.
[2nd import]
cvs import -ko -kb -I!
cvs rtag -d
cvs rtag
cvs checkout -D -r
The rtag -d and the subsequent rtag commands are necessary so that checkout
picks out the latest i.e. the 2nd import. And 'cvs checkout' works with
either -D or -r but not together after the 2nd import. (OK, the -D option on
its own is rather pointless as far as we're concerned.)
Hope this is clear.
Thanks
sc
]-Original Message-
]From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
]Sent: Thursday, May 29, 2003 2:55 PM
]To: [EMAIL PROTECTED]
]Cc: [EMAIL PROTECTED]
]Subject: Re: FW: cvs import & checkout -D date_spec
]
]
]Chen, Susie writes:
]>
]> It does not seem time zone is the issue here, unless I
]> misunderstood something. Both the server and the client are in
]> the same time zone. As I said, the same CVS checkout command,
]>
]> cvs checkout -D -r
]>
]> used to work with the 1st import. It does not work after the
]> 2nd import. And because the import was for a branch, I have to
]> re-tag so that a check out picks up the latest (i.e. the 2nd
]> import). Indeed, a checkout without the -D works fine and
]> picks up the latest. And checkout with -D and without -r also
]> works fine. There seems to be some conflict between -D & -r.
]> But what's interesting is that checkout with -D and -r works
]> fine before the 2nd import!
]
]It would be helpful if you showed us the exact commands you used, the
]results you got, and exactly how that differs from what you expected.
]Also, what versions of CVS you are using ("cvs version" will show both
]the client and server versions). "Doesn't work" is a bit nebulous.
]
]-Larry Jones
]
]Pitiful. Just pitiful. -- Calvin
]
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Tags and module file
Hi All This is a query regd - branches (special tag) or tags and module file. Is it somehow possible to include one tag in one module defination and another tag in another module defination ? ^^Regards Gurpreet S ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The idea isn't clear...
On Wed, May 28, 2003 at 07:29:58PM -0400, Greg A. Woods wrote:
> [ On Wednesday, May 28, 2003 at 15:24:09 (-0700), Jim wrote: ]
> > >>>
> > stuff
> > ===
> > other stuff
> > <<<
>
> It's one hell of a lot easier to tell what's going on with conflicts if
> you fix CVS to call "diff3" in such a way that it includes the full
> conflict information:
[reluctantly quoting almost the entire patch, since I don't see
how to edit it down...]
> $ cvs diff rcscmds.c
> [...]
> ***
> *** 245,254
> --- 245,258
> char *tmp1, *tmp2;
> char *diffout = NULL;
> int retval;
> + struct stat file_info;
>
> if (options != NULL && options[0] != '\0')
> assert (options[0] == '-' && options[1] == 'k');
>
> + if (CVS_STAT (workfile, &file_info) < 0)
> + error (1, errno, "could not stat %s", workfile);
> +
> cvs_output ("RCS file: ", 0);
> cvs_output (rcs->path, 0);
> cvs_output ("\n", 1);
I suspect that the above diff hunk is an unrelated change. It
seems unrelated to the conflict-marking style.
> ***
> *** 298,305
> only for diagnostic messages -- CVS no longer forks to run diff3. */
> diffout = cvs_temp_name();
> call_diff_setup ("diff3");
> ! call_diff_arg ("-E");
> ! call_diff_arg ("-am");
>
> call_diff_arg ("-L");
> call_diff_arg (workfile);
> --- 302,308
> only for diagnostic messages -- CVS no longer forks to run diff3. */
> diffout = cvs_temp_name();
> call_diff_setup ("diff3");
> ! call_diff_arg ("-ATam");
>
> call_diff_arg ("-L");
> call_diff_arg (workfile);
I used to make this change too (well, the s/-E/-A/ part; the -T
is orthogonal), but recently discovered a drawback -- for me,
it's a showstopper; I've had to revert the change.
Suppose you make a local change to a third-party package (I use
the vendor branch, but I strongly doubt that's relevent). You
submit your change, and it's incorporated without modification
into the canonical source. When you merge after importing the
new version, CVS decides that what looked at first like a
conflict, really isn't, because the "conflicting" change is
identical in both child versions. CVS just accepts the change,
and prints this message:
${file} already contains the differences between ${rev1} and ${rev2}
The problem is that the s/-E/-A/ patch breaks this detection, and
instead of a nice message, you get spurious merge conflicts.
I think the problem is in diff3. -A does two things:
1. makes diff3 dumber about identifying conflicts (suppresses
the intelligence that would have suppressed the conflict in
the above case)
2. once a conflict has been identified, displays its ancestor
version as well as the two child versions
Of course, (2) is what we're after, but diff3 provides no way to
get that without also getting (1).
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
