bug-cvs
[Top][All Lists]
Advanced

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

[patch #4809] Tag extension for builtin tags


From: Derek Robert Price
Subject: [patch #4809] Tag extension for builtin tags
Date: Thu, 19 Jan 2006 15:02:37 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Update of patch #4809 (project cvs):

                Category:         Feature Request => Feature (patch attached)
                  Status:                    None => In Progress            

    _______________________________________________________

Follow-up Comment #1:

To browse the current version of the sources based on this patch:

http://cvs.savannah.nongnu.org/viewcvs/ccvs/?root=cvs&only_with_tag=newtags2


Some starting points in the mail archives with previous discussion:

http://lists.gnu.org/archive/html/bug-cvs/2005-04/msg00009.html
http://lists.gnu.org/archive/html/bug-cvs/2005-04/msg00065.html
http://lists.gnu.org/archive/html/bug-cvs/2005-03/msg00104.html


Finally, I'm not sure we resolved all the issues regarding .root & .parent. 
I'm not even sure we discussed them all.  What happens, for instance, when a
checked-out branch looks like:

file1 1.3.2.1.2.1
file2 1.9
file3 1.76.6.3.2.1
file4 1.102.6.9

Assuming that MYBRANCH is attached to:

file1 1.3.2.1.0.2
file2 1.9.0.8
file3 1.76.6.3.0.2
file4 1.102.6.9.0.2

Does MYBRANCH.root return:

file1 1.3.2.1
file2 1.9
file3 1.76.6.3
file4 1.102.6.9

?


Looking at your implementation, I can only say it might without testing, but
your implementation looks much too mathematical.  With the simple restriction
that `.root' may only be applied to named branches, which I should think would
be the most useful application of .root anyhow, simply looking the branch up
in the symbols table and de-magicing the revision you find should yield the
above result.  Anything else lacks determinism with files that may not have
been checked in on a branch.

I think your .origin implementation may have a similar lack of determinism
when dealing with subbranches (what's the result of MYBRANCH.origin when
MYBRANCH is a sub-branch or YOURBRANCH with no commits?) and a similar
restriction to working with named branches would simplify the
implementation.

I suppose it would be okay to leave the current implementations in place for
when the .root and .origin are requested for a single revision of a single
file, but I think the BRANCH.root implementation is important.  I'm not as
worried about BRANCH.origin since I still don't really understand why .origin
is useful anyhow.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?func=detailitem&item_id=4809>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

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