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

Submitted by:  None
Submitted on:  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>
Project 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)'.



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


Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.




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