Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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