info-cvs
[Top][All Lists]
Advanced

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

Re: Import and merge into branch


From: Greg A. Woods
Subject: Re: Import and merge into branch
Date: Wed, 3 Nov 2004 16:59:20 -0500 (EST)

[ On Sunday, October 31, 2004 at 20:59:56 (-0800), Mark D. Baushke wrote: ]
> Subject: Re: Import and merge into branch 
>
> There is no risk of cvs getting confused by creating a new branch from a
> version tag of any kind.

That's not exactly true in all cases.  ;-)

CVS will get confused if a new "normal" branch is created (i.e. with
"cvs tag") in a module created with "cvs import" and then another
subsequent import is done and an attempt is made to merge it.

CVS "vendor" branches do not co-exist well with "normal" CVS branches
due to the optimizations used and due to the hackish "default branch"
magic used for vendor branches.

As you know the mechanics are rather complex to work through but suffice
it to say that newly imported changes can suddenly appear in the wrong
places when vendor branches and normal branches are mixed.  I see this
too regularly in the NetBSD repository where I do all my local work in a
directory that was checked out from a "normal" branch and where
sometimes "cvs import" is used imporoperly to update third-party code
and where local changes are also made on the trunk of that third party
code.

Of course as you suggest below it is also true that even just with the
normal "vendor branch" management tactics, i.e. even when no "normal"
branches exist, that the whole module in the repository is in an
inconsistent state between the time the import is started and the time
the commit of the merge of new vendor changes to the trunk of locally
changed files is completed.

> Future direction change:
> The cvs 1.12.10 (not yet released) will have a -X option to import that
> allows you to import and not be visible on the main trunk by default.
> Version 1.1 exists (it always needs to be created) and version 1.1.1.1
> is the first imported version, then with -X a dead 1.2 version is
> created right away. This protects the main trunk from imports that might
> confuse it and allows you to merge vendor files into the main trunk in
> a controlled commit in conjunction with other mainline files.

I don't think that's really going to help much in the case where normal
changes also exist, but I've not thought it through entirely.

I.e. I think one would also have to get rid of the reliance of the
"default branch" hack in vendor branched modules in order to make it
work as safely as possible.

I.e. the "right" thing to do would be to completely eliminate the stupid
"1.1.1" branch junk and to always create and treat the vendor branch as
a "normal" branch and to always do a full "commit" of new vendor
releases to that branch and then to a normal, manual, merge of the
changes on the vendor's branch to the, or to each, local branch as
necessary.  Such a change would of course be incompatible with existing
repositories containing the current style vendor-branched modules.

-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>




reply via email to

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