[cvsnt] Import generates conflict messages, why???

Bo Berglund bo.berglund at telia.com
Tue Nov 23 23:12:37 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.


On Tue, 23 Nov 2004 13:35:50 +0000 (UTC), "Oliver Giesen"
<ogware at gmx.net> wrote:

>Bo Berglund wrote:
>
>> And I am not using any branches, this is because these sources are
>> supposed to build a proper module with a progressive revision history
>> on TRUNK rather than creating multiple branches... 
>
>I think you're having a misconception there. Multiple Imports do not
>create multiple branches unless you specify a different vendor branch
>for every import (which you shouldn't).
>
>I really don't get the fuss about the vendor branch. It's a mere
>cosmeticality really. As soon as you start adding your own changes,
>they will still be on the trunk.
>
>There's simply too much power in the Import command that I would never
>want to sacrifice just for the sake of getting a cleaner revision graph
>- because that's pretty much the only thing you gain if you don't use
>it.
>
So now at home I did an import test:
I imported 4 sets of the same files using the Vendor tag Module1 on
all imports and varying the release tag from Version1 to Version4.
I edited some of the files (not all) between the imports to simulate a
true module history.

After I had done this I checked out the imported module and looked at
the result.
First observation:
All revisions shown are 1.1-based (1.1.1.1, 1.1.1.2, 1.1.1.3 etc)

Second observation:
There is no sign of the branch tag in the WinCvs display. Strange
since the revisions indicate that there is a branch involved.

Third observation:
I used the WinCvs graph function and I could see that the files are on
a branch called Module1. All revisions go down that tree. And there
are revision tags as usual and they are the release tags from the
import.

4th observation:
If I try to update the sandbox to one of the release tags or to the
branch tag I invariably get this response from cvs:

cvs -z9 update -P -r Version3 (in directory
F:\Engineering\Projects\Antares\PC\ImpTest\)
cvs [server aborted]: no such tag Version3

Then I do a status on a file in the module:

   Existing Tags:
	Version4                 	(revision: 1.1.1.3)
	Version3                 	(revision: 1.1.1.2)
	Version2                 	(revision: 1.1.1.2)
	Version1                 	(revision: 1.1.1.1)
	Module1                  	(branch: 1.1.1)

Now the 64.000$-question is:
Why is it not possible to update the sandbox to a clearly existing tag
when said tag was created during an import????

This surely does not look like a powerful tool to me since I cannot
even get the files out of there using tags as I am used to...


/Bo
(Bo Berglund, developer in Sweden)



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