patchConcurrent Versions System - Patches: patch #4809, Tag extension for builtin tags


You are not allowed to post comments on this tracker with your current authentication level.

patch #4809: Tag extension for builtin tags

Submitter:  None
Submitted:  Wed 18 Jan 2006 01:15:57 PM UTC
Category:  Feature (patch attached) Priority:  5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  None Originator Email:  -email is unavailable-
Open/Closed:  Open Fixed Release:  None
Fixed Feature Release:  None

Sat 21 Jan 2006 12:14:23 PM UTC, comment #2: 

This patch agains newtags2 fixes detection of BRANCH.origin for BRANCH not having any commits.
It also includes the fix for some compiler warnings that has been sent before but not jet been applied.

Thu 19 Jan 2006 03:02:37 PM UTC, comment #1: 

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

Some starting points in the mail archives with previous discussion:

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:

file2 1.9

Assuming that MYBRANCH is attached to:


Does MYBRANCH.root return:

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

Derek Robert Price <dprice>
Group administrator
Wed 18 Jan 2006 01:15:57 PM UTC, original submission:  

A branch 'newtags2' has been started. It coveres implementation of several new tags:
and the required fns to deal with these tags.
Details can be taken from the docs, subsection 'Tags (builtin)'.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #9459:  ccvs-newtags-diff-2006-01-21-13-08-37.patch added by None (12KiB - text/x-diff - Fix for BRANCH.origin without commits on BRANCH)


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-01-21 None Attached File- Added ccvs-newtags-diff-2006-01-21-13-08-37.patch, #5793
2006-01-19 dprice CategoryFeature Request Feature (patch attached)
    StatusNone In Progress
2006-01-18 None Carbon-Copy- Added frank --AT-- hemer --DOT-- org

Back to the top

Powered by Savane 3.13-4b48.
Corresponding source code