[cvsnt] Feature request: Commitable tags

[Tuomas Huhtanen]

Max Bowsher wrote:
> OK, just as a summary:
> 
> Commitable tags are a kind of just-in-time branching, the idea being to
> avoid the need to branch and then repeatedly merge when multiple lines of
> development share the same file but are very unlikely to change it. (An
> example: a new feature being developed in a complex project - only a subset
> of files will contain actual changes, the rest only redundant copies of the
> trunk changes, as they are merged into the branch).

Yes, the idea is to be able to do just-in-time branching. But there is 
more than just the just-in-time branching. There comes a bunch of 
implicit features along.

One aspect is that the developer cannot commit to a commitable tag if 
there is new revisions made to the file after the tag has been last 
updated (because the tag is not anymore in the leaf revision). So that 
forces the developer to make the "merging"(updating the tag/creating a 
branch) decision as early as possible. (It would be identical to the 
situation where developer tries to commit his changes to outdated revision)

One aspect is that you would get visual hints about how close the 
different releases are to each others, because the tags point to the 
same revision, not different but identical revisions. Even if they would 
not point to the same revision, the tags would still be close to each other.

One aspect is that the codebase would become kind of self organizing to 
logical modules (in version sense). Since you wouldn't create branches 
to files you dont need to branch, they remain in the last needed "module 
branch".

But yes, the biggest plus is the ability to create branches only when 
needed.

> The huge drawback is that you lose history tracking of the correllation
> between files merely accepting trunk changes and those actually being
> modified on the branch.

I'm not sure I understand what you are saying here. Care to elaborate?

Tuomas


> The co/up -f flag is a _partial_ solution to this kind of problem, but would
> need to be made sticky, amongst other changes.
> 
> 
> I believe that the true answer to this problem is to simply merge regularly.
> (And perhaps implement some kind of extension to the RCS file format so that
> a revision can say "I have no changetext of my own, I am exactly equal to
> <revnum>".)
> 
> 
> Max.
>