I'd be inclined to agree here. One particularly common use case for having
files with different casings is when a file is incorrectly cased on first
commit.
One runs cvs rm, renames the file then re-adds it (as following the right
way of doing things). In this case, there is never a sandbox
Eric Siegerman [EMAIL PROTECTED] wrote:
Instead, perhaps it should do something like: if the specified
pathname, together with the usual other criteria (-r, -D, sticky
attributes, etc.), selects more than one *revision*, complain.
The existing (I think) test cares about theoretical
Kevin Layer writes:
Eric Siegerman [EMAIL PROTECTED] wrote:
Instead, perhaps it should do something like: if the specified
pathname, together with the usual other criteria (-r, -D, sticky
attributes, etc.), selects more than one *revision*, complain.
The existing (I think) test
On Tue, Sep 16, 2003 at 10:31:07PM -0400, Larry Jones wrote:
Eric Siegerman [EMAIL PROTECTED] wrote:
Instead, perhaps it should do something like: if the specified
pathname, together with the usual other criteria (-r, -D, sticky
attributes, etc.), selects more than one *revision*,
On Thu, Sep 11, 2003 at 11:54:20AM -0700, Kevin Layer wrote:
cvs [server aborted]: CHANGE-LOG,v is ambiguous; could mean CHANGE-LOG,v or
change-log,v
On Thu, Sep 11, 2003 at 01:05:13PM -0700, Kevin Layer wrote:
Lots of instances of the following in my repository:
foo,v
Attic/Foo,v
I'm running the cygwin 1.11.5 client on Windows 2k sp4.
Got this when I updated today on Windows, after upgrading to 1.11.6
yesterday on the linux RH server (2.4.22 kernel):
D:\acl7\src\clcvs update -d
cvs server: Updating .
P ChangeLog
cvs update: move away ./Makefile; it is in the way
C
I'm running the cygwin 1.11.5 client on Windows 2k sp4.
Btw, upgrading cygwin, which contaains 1.11.6, does not fix the
problem.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Kevin Layer writes:
cvs [server aborted]: CHANGE-LOG,v is ambiguous; could mean CHANGE-LOG,v or
change-log,v
CVS was designed for case-sensitive file systems and has never quite
worked entirely correctly on case-insensitive file systems. Client/
server mode where one system is case sensitive
Lots of instances of the following in my repository:
foo,v
Attic/Foo,v
where the Attic file was cvs rm'd years ago and is not used anymore.
If I rename Attic/Foo,v to Attic/Foo_renamed_due_to_cvs_bug,v and cvs
update -d on my Windows box, all is well.
