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)