[cvsnt] Feature request: Commitable tags

[Tuomas Huhtanen]

Tony Hoyle wrote:
> If you can change a tag it's a branch...  A tag specifies a single revision
> only, as that's it's purpose.  You can move tags (although that should be done
> as little as possible), but they can't hold more than one revision.

I know that tags are mostly used to specify a release/revision of the 
system as it was at some specific time. But there are no technical 
obstacles to use the tags differently. And that's what I'm suggesting 
here, a little more flexible usage of the branches and tags.

I dont want a single tag to hold multiple revisions (altough i dont even 
know what you mean by that), I just want a little more flexible way to 
use the tags.

> If you want to commit a change to several branches that's what merging is
> for...  There isn't another practical way to do it other than the way it's
> done now, because you're dealing with different code & have to merge
> differently in each branch (with possible conflict resolution).

I'm not talking about situations where you commit changes to different 
branches. I'm talking about commiting a change to multiple 
releases/revisions. And specifically about situations where the file 
revision does not need to be different in the different releases.

I try to lay out a new example here. There is one file A in the 
repository, and a need for three different releases, R1, R2, R3.

How we would do it today:
Create branches b_R1, b_R2, b_R3
edit file A in b_R1.
merge change to branches b_R2 and b_R3
(Now we have three different, but identical revisions (plus the original)

now edit A again in b_R1.
This is a change we want only to be in b_R1, so we wont merge it anywhere

and finally edit A in b_R2, and merge to b_R3
(Now we have three different revisions, of which two are identical (plus 
previous revisions))


How I would like to do it:
Create commitable Tags ct_R1, ct_R2, ct_R3
edit the file A in the ct_R1 (meaning that I have checked out ct_R1, the 
  file actually resides in the main trunk)
update tags ct_r2 and ct_R3 to point to the same revisoin as ct_R1 does.
(Now we have single revision with three tags pointing to it (plus the 
original revision))

now edit A again in ct_R1
This is a change we want only to be in ct_R1, so we wont do anything 
else now.

and then we edit A in ct_R2. Now if we try to commit it, we cannot do 
it, since ct_R2 is now outdated. Now we need to branch the A to b_R2 and 
  commit the change there. Also because we want the change to ct_R3, we 
update the ct_R3 to point to the b_R2 revision.
(Now we have two revisions with two tags pointing to one and one tag 
pointing to the other)



I know the philosophy how to use the branches and the tags differs from 
the traditional way, but technically it does not differ that much.

I would still use branches as branches, but the difference is that the 
branches are created only when needed, not when one file out of the 
whole bunch needs the branch.

I think that the basic implementation in code wise is also very simple. 
When commiting, instead of checking is the sticky tag branch:

		if (status == T_MODIFIED && vers->tag &&
		    !RCS_isbranch (finfo->rcs, vers->tag))


we could check if it is a branch OR a writable tag.

Of course there are some other modifications needed also, e.g. when 
creating the tag, the information needs to be stored that the tag is a 
writable tag.

But that is pretty much it what is needed in the basic implementation. 
Some additional nice-to-have features could be something like "update 
writable tag", which could move the writable tag to the leaf revision of 
   the branch the file is in (if there is no branchpoints in between).

Hope this illustrated the idea a little further,
Tuomas