[cvsnt] Feature request: Commitable tags

[Tuomas Huhtanen]

Hi,

Could it be possible to implement such a tag to cvs that allows
commiting to that tag? So that it would not be branch, but instead it
would commit the change to whatever branch the tag is in.

Background:
Currently we create a new branch for each release (version) of the
software. Bugfixes go usually to every active branch, which might be for
example four different branches. So in current situation I have to
commit the same bugfix to each branch and cause the revisions of the
files be different. There is clearly quite an overhead commiting the
changes to all these branches.

Now I would like it to be so that these four releases of the software
would not be in their respective branches. Instead I would just like to
have tags to point to the corresponding release and when needed, the
subset of the release is branched. Theoretically I can operate as
described above, but it is not very practical (at least not in any way
I'm aware of). I can checkout the release with the release tag and force
commits to the branch underneath the release with -r option. But the
problem is that when I'm working on some release tag, I really don't
want to know what the underlying branch is. If I for example commit 200
different files at a time, I would basically have to check the branches
of the files individually. Also, if I force the commit to some branch,
the release tag is not moved, which is quite inconvenient.

The benefits of using cvs in the described way is that the headache of
when to create a branch is gone. You would not be creating the branches
until you really need the branch. The release tag, on the other hand,
can be created virtually whenever.

One major benefit (at least I see it as a benefit) would be that the
developer of certain release is forced to make the decision whether or
not to include the commits to the release. For example file A revision
1.1 has tags REL_1 and REL_2. Developer commits a bugfix to REL_1, now
we have revisions 1.1 (REL_2) and 1.2 (REL_1). The developer should of
course move the tag REL_2 also to 1.2, but if he doesn't, nothing can be
commited to the REL_2, before an explicit decision is made whether or
not to include the fix in REL_2. 

Thanks, 
Tuomas Huhtanen