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 email@example.com.
Gerhard Fiedler schrieb: > If I understand you correctly, this shouldn't be. What says the cvs status > of one of these rogue files? Yes you understood correct: this shouldn't be. I'm not sure whether this is a "special behaviour" of vendorbranches or of "cvs import" - or a combination of both. The situation(CVS-behaviour is following - as I understand: * When I have a new USERBRANCH and I ADD a new file to this branch, this file will not be available on the trunk unless I do not merge from userbranch to Trunk. * When I do an INITIAL IMPORT of files to an VENDORBRANCH (nothing has been there before in the repository) the files will be available on the TRUNK (as revision 1.1) as well as on the vendorbranch (revision 18.104.22.168). Checking out the trunk will work as well as checking out the vendorbranch - I will get BOTH times the same files ... Furtheron unexpected behaviour occurs (and that's my problem): * Importing on a second VENDORBRANCH the following problem occurs: 1. Modified files on the second vendorbranch (modified in comparison to the initial vendorbranch) were imported correctly. They exist as version 1.1 on trunk, 22.214.171.124 on the initial vendorbranch and 126.96.36.199 on the second vendorbranch, where revisions 1.1 and 188.8.131.52 are identical 2. New files on the second vendorbranch (files that are new in comparison to the initial vendorbranch) were imported in that way that they exist as revision 1.1 on the trunk and 184.108.40.206 on the second vendorbranch. They don't exist on the initial vendorbranch. Checking out the trunk, I will get all 1.1 revisions - without any differentiation whether they origin from initial vendorbranch or the second vendorbranch ... On one hand that's "correct" behaviour - that's how importing of vendorbranches works: new files were imported as vendor-revision on the branch (Revision 220.127.116.11 or 18.104.22.168 or 22.214.171.124 ...) and as 1.1 on the trunk. Checking out the trunk I will get all 1.1 revisions ... But on the other hand that's a "messy" behaviour, since it cannot be distinguished on the trunk, which vendorbranch is the source of those files ... Johannes P.S: cvs status -v -- xxx.cgi (in directory G:\Projekte\Temp\Test) =================================================================== File: xxx.cgi Status: Up-to-date Working revision: 126.96.36.199 Repository revision: 188.8.131.52 /Repo/Test/xxx.cgi,v Expansion option: kv Commit Identifier: (none) Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Merge From: (none) Existing Tags: second_Vendortag (revision: 184.108.40.206) second_Vendorbranch (branch: 1.1.3) ***** CVS exited normally with code 0 *****