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.
I think it works like this: 1. You want to import a source tree to a *repository* (please use the correct words in order not to confuse issues...). 2. When you do this you will effectively create a new *module* with your sources in the given repository. 3. If you don't do anything the imported files will be put on the so called "vendor" branch and will start out as revision 1.1.1.1 (You can force CVSNT to import to TRUNK which gives you revisions 1.1) 4. Then you check out the newly imported *module* to a new sandbox location. (this step can be avoided if you tell CVSNT to convert the source tree to a proper sandbox during import). The checkout will get you the files into the TRUNK, but they are still revision 1.1.1.1 coming from the vendor branch. 4. Now you work on these files and commit your changes, when this happens all your changes go to the TRUNK and so the revisions will be 1.2. 5. In order to still work on the vendor branch you must perform an additional step after the checkout, you have to update your sandbox to the vendor branch. But this is not how the CVS import function is supposed to work, the vendor branch should only contain the vendor's own changes, not your own edits. Anyway, if you work off the vendor branch the next revision of a committed file will be 1.1.1.2 6. If you create a branch of your own off of the vendor branch then the files committed to this branch will get revision numbers like 1.1.1.1.2.1 or similar. In order to avoid all of this you can initially import the sources to create a *module* in your *repository* with the CVSNT command line switches to NOT create the vendor branch and to convert the source tree to a sandbox. Go to the top folder in the tree you want to import and execute this command: cvs -d:sspi:cvsserver:/repo import -C -n -m"An import message" Projects/MyImport (of course replace the -d parameter with your own server info and also the destination module you want to put the sources into) /Bo -----Original Message----- From: jacob.alvarezbenedicto at telefonica.es [mailto:jacob.alvarezbenedicto at telefonica.es] Sent: den 26 april 2005 12:18 To: Bo Berglund; cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: RE: [cvsnt] Re: Unmodified files committed when merging from a branch Hi, Thanks for the answer. So let me make sure that I have understand. The repository was created with a vendor branch, (when I became the admin the repository was already created), and this is the "origin" of those merged unmodified files that have to be committed. This will only happen when the HEAD commits revision 1.2 or more and then we do the merge from the branch with a 1.1.1.1.2.1, for example. Am I rigtht. If in the HEAD branch the revision is still 1.1.1.1 (due to the vendor branch revisions number) then it should be no problem, and that could explain why are only some file that suffer from unmodified-merge-commit-syndrome :-). At last, this can only happen with a file only once, when the context of the file is changed then the other merges should go alright (I mean if there are no difference it won't appear as modified). Am I right. ?? Thank you very much. Jacob