bug-cvs
[Top][All Lists]
Advanced

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

Re: sticky tags don't update for added/removed files


From: Derek Robert Price
Subject: Re: sticky tags don't update for added/removed files
Date: Thu, 09 May 2002 13:11:33 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020501

Jim Meyering wrote:

Hi Greg!

This sure sounds like a bug/oversight to me.


I think I may have rejected this in the past. I'm not quite sure what I was thinking. Well, I think I may, but it wasn't consistant with CVS operation. Anyhow, I'll second (or third) that this is a bug/oversight now.

Greg McGary <greg@mcgary.org> wrote:

Consider this scenario:

* check-out or update to a branch "foo".
* create a file, sticky tag is "foo".  Good.
* remove a file, sticky tag remains "foo".  Good.
* update to another branch tag with `-r bar', or back to trunk `-A'.
 The added file and the removed file still have "foo" as their sticky
 tags.  Bad.  (All other files have properly updated sticky tags)

It smells like a bug, but I thought I'd see if there was some subtle,
inscrutable reason why this behavior might be desirable.

If it's a bug, I volunteer to fix it, since I need it done within a
week.  8^)

Some possible wrinkles:

* removed file in old branch has different revision in new branch:
 should treat as conflict

* removed file in old branch has already been removed in new branch:
 seems like a noop, and the removal should be considered already
 complete.


I'm not sure I like the idea of losing the `locally removed' mark,
but I suppose doing as you suggest is consistent with e.g., how
a merge works when merging in a change that's already present
in working sources.


I'll second this too.

* file added to old branch already exists in new branch:
 should treat as conflict (unless perhaps file content is identical,
 in which case the addition should be considered already complete?)


I don't feel too strongly about it, but am inclined to say
it deserves a conflict even if they happen to be identical.


Why? What's the difference between that and the "Changes already contained in X" change merge analogy?

Jim


Derek

--
               *8^)

Email: derek@2-wit.com
Public key available from www.keyserver.net - Key ID 5ECF1609
Fingerprint 511D DCD9 04CE 48A9 CC07  A421 BFBF 5CC2 56A6 AB0E

Get CVS support at http://2-wit.com
--
He who laughs last thinks slowest.






reply via email to

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