info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updated to 1.11.6 (from 1.11.2) now have problems on windows


From: Eric Siegerman
Subject: Re: updated to 1.11.6 (from 1.11.2) now have problems on windows
Date: Mon, 15 Sep 2003 23:43:33 -0400
User-agent: Mutt/1.2.5i

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
> 
> 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.

More or less shooting from the hip here, since I haven't checked
the code:  a more sophisticated "is ambiguous" test might solve
this.

What does "ambiguous" really mean here?  I think it should mean,
"you're asking me to check out two revisions into the same file
in the sandbox."

In Kevin's situation, if a Windows user types
    cvs update -A foo
(or "cvs update -A FOO", or whatever), that will select a live
revision from foo,v, but only a dead one from Attic/Foo,v, so
it's not really a problem in practice.  Similarly, if tag OLD_TAG
was applied before the case-renaming was done,
    cvs update -r OLD_TAG foo
would select only a revision from Attic/Foo,v since the tag
won't exist in foo,v -- again not a problem.  It's only if the
user types something that matches a (non-dead) revision in each
file, that there's a collision, e.g.
    cvs update -r1.3 foo
when both foo,v and Attic/Foo,v happen to contain live 1.3
revisions.

I'm guessing that what the "is ambiguous" test does now is, "if
the specified pathname selects more than one file in the repo,
complain".

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 ambigity; my
proposed one cares only about the practical problem -- the
impossibility of stuffing two unrelated revisions into one
sandbox file.  If an operation isn't trying to do that,
forbidding it on theoretical grounds seems pointlessly annoying.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]