Re: about imports and cvs update

[Harry Putnam]

Michael Haggerty <address@hidden> writes:

> Harry Putnam wrote:
>> I don't do many imports... maybe 5-5 in the last 10 yrs..
>> And never did one that was not the start of a new repository.
>> 
>> Is it a misuse of import to use it to start a new directory hierarchy
>> beneath some exiting hierarchy in CVSROOT?
>
> IMHO "cvs import" should only be used to create a vendor branch, which
> is a branch that is used to actively track sources from a third party.
> There is no need to use "cvs import" to get your own source code into
> CVS, as it does lots of extra stuff that is useless when not tracking
> third-party sources.  There are also several aspects of vendor branches
> that are not recorded carefully by CVS, so the (ab)use of vendor
> branches can make it harder to migrate away from CVS when that
> inevitable day comes.
>
> To add a new directory hierarchy within a CVS repository, simply check
> out a working copy, copy the new directories to the right place in the
> directory hierarchy, then use "cvs add" and "cvs commit" to put them
> under version control.

Well, that is true, but that method requires a lot more hand work if
the added sub hierarchy is more than 1 directory and a few files.

So does cvs not offer any method to add a whole chunk of directories
and files en masse.

Once an import has been done, as in this case.. is there any
continuing harm?

What I did to get back on an even keel was delete the checked out
module that shows no updates needed, and re-checkout.. this time the
import is present.

So will I have continuing problems with that sub hierarchy?

" . . . . . . . . . . . . . . . . . .  so the (ab)use of vendor
> branches can make it harder to migrate away from CVS when that
> inevitable day comes."

Sounds like you think cvs is on its last legs... I had hoped to
continue using it for a good while yet.  Is it likely to fall out of
development?

To me, some of the alternatives like subversion or git, seem really
confusing, at least in there documentation, (I've used neither) with
there emphasis on revisions depending on the whole repo snapshot.