[cvsnt] Multiple tag names on 1 branch causing problems

John W. Hoey jwh02 at health.state.ny.us
Tue Mar 2 12:53:59 GMT 2004


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.


Back in January, a problem occurred where someone  mixed up the the vendor
and release names on an import ( ex. cvs import myModule REL_C  VENDOR_A ).
This had the apparent  effect of creating a new branch, moving the most
recent import and all previous  revisions to the new branch, and leaving
the previous branch empty. Also the  revision tag was ignored.
http://www.cvsnt.org/pipermail/cvsnt/2004-January/009956.html
http://www.cvsnt.org/pipermail/cvsnt/2004-January/009960.html

In version 2.0.20, there was an attempt to fix this  problem:
http://www.cvsnt.org/pipermail/cvsnt/2004-January/010030.html

The problem however was not in branching, but in  tagging. Imports always
go on the 1.1.1 branch by default. The import put the new revisions on
branch 1.1.1 as it always does, and tagged the branch with the 'release'
name, giving branch 1.1.1 two tag names. The  release tag was ignored since
it already existed as a branch tag. The graphing portions of the CVS front
ends I use ( WinCvs, Tortoise ) expect that a branch ( 1.1.1, 1.1.2,.1.1.4
)  will only have 1 tag name. If it finds two tag names it assumes there
are two  branches, even though there is actually only one. All revisions
will appear to be under the latest branch tag name.

The fix in 2.0.20 had the effect of forcing a  different branch tag for
every import. Since all imports go to the 1.1.1 branch by default this has
the effect of forcing multiple branch tags on a single branch, a  situation
which some CVS front ends cannot handle correctly.

Below is a previous note I sent on this subject  with a detailed example.
http://www.cvsnt.org/pipermail/cvsnt/2004-February/011069.html

The fix put in in 2.0.20 does not change the actual branch or revision
where a new import resides. It does not solve the original problem ( using
the wrong vendor tag ), but actually enforces that behavior. Since having
multiple names for the same branch is confusing for both the developer and
the CVS clients ( particularly graphing ), I am asking that the fix put on
in 2.0.20 be removed.

Thank you,
John Hoey

P.S. FYI You can import to a different branch by using the -b option, ex.
import -b 1.1.3 myModule Vendor_2 Release_1.  The key point is that on
import you specify the branch ( 1.1.1, 1.1.3, etc. ) and branch name
independently, as oppossed to tag and rtag where you specify that a new
branch should be created and named with the tag specified ( effectively
limiting branches to 1 name).





More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook