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).