info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: import vs add


From: Jim Hyslop
Subject: Re: import vs add
Date: Wed, 14 Dec 2005 21:38:15 -0500
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Piotr Fusik wrote:
> I'm about to upload my sources to my new sf.net project.
> I'm now wondering whether I should use "cvs import" (which seems
> to be recommended in sf.net docs) or "cvs add" (which seems
> to be possible and more straightforward).
> 
> I have read the whole CVS manual and browsed the web for a while
> and found no good answer.
> 
> Does "cvs import" do anything in the repository that cannot be done
> with a couple of "cvs add", "cvs commit" and "cvs tag" ?
It is recursive. 'cvs add' is not. Also, cvs import sets the default
branch to the vendor branch specified on import.

> I see several problems with "cvs import":
> 
> 1. What vendor and release tags to use for a fresh GPLed project?
> I'm not a vendor and the initial import is no real release.
Just make up something, since they're meaningless anyway. Once the
import is complete, you can reset the default branch, remove the branch,
and remove the tags.

> 2. Are these tags magical in any way, or just regular tags like these
> created
> with "cvs tag" ? Can they be deleted later?
The only magic about them is the special vendor branch it creates, with
the odd number in the third position ("normal" branches have an even
number). Other than that, they're normal tags and branches.

> 3. It seems that "cvs import" normally creates the 1.1.1 branch and
> 1.1.1.1 revisions.
> I don't think I need them. In contrast, "cvs add" creates just 1.1
> revisions, which is simple.
See #5

> 4. If import creates 1.1.1.1, why the next commit turns it into 1.2
> and not 1.1.1.2 ?
Import is designed to work with third party source. CVS imports the
files onto a branch (the vendor branch), but if you provide local
customizations, you want to keep the vendor branch clean of your
changes, so your changes get checked into the trunk. Then, when the
vendor provides a new release, you re-issue the import command,
specifying the same vendor branch tag, and cvs adds the new versions as
1.1.1.2. You can then merge the vendor's changes into your customizations.

> 5. 1.1.1.1, 1.2, 1.3, ... revisions just don't look good. I don't see
> any reason why the files
> I add later (using "cvs add" -> revision 1.1) should appear different
> from the files I upload
> initially.

Because you didn't import them, you added them. Add always starts at 1.1
(or 1.1.2.1 if you initially add to a branch, but then the branches
behave as you expect). Import always starts on a branch.

If you really don't like them (and I don't blame you) then you can
always reset the default branch ('cvs admin -b'), delete the 1.1.1.1
revision ('cvs admin -o rtag'), and delete the tags. For some reason,
'cvs tag -d' doesn't seem to work with these tags, so I had to use 'cvs
admin -n' instead.

- --
Jim Hyslop
Dreampossible: Better software. Simply.     http://www.dreampossible.ca
                 Consulting * Mentoring * Training in
    C/C++ * OOD * SW Development & Practices * Version Management
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDoNcXLdDyDwyJw+MRAghOAJ9GSaGGQxiC27eYDX4Wb5usa+t6ugCfbTR1
d0CB365nXUkMwsotjDnjbFc=
=pdpQ
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]