[cvsnt] Re: vendor branch and import problem
news at derived-software.ltd.uk
Thu Feb 26 16:34:14 GMT 2004
On 2004-02-26, Tony Hoyle <tmh at nodomain.org> wrote:
> Vendor tags aren't really branches... you don't normally commit to
> them. Anyway, we're not talking about committing a new revision to a
> branch - that's not what import does. It actually overwrites the
> existing branch with a completely new one, creating an orphan branch
> if you've changed any revisions on it (which you never would have
> normally... which is why they're really tags).
I don't understand the problem with the old behaviour.
Or, more to be point, I don't have a problem with the old behaviour,
and it works for me.
I get a release of a third party library (let's call it "boost").
I import it. Vendor: www_boost_org; Tag: boost-1_29_0.
All files are imported on to branch 1.1.1 (as version 184.108.40.206).
Version 1.1 exists for all files and is not "dead".
I decide I want to make some changes - I do so on the trunk.
A new version of boost comes out.
I import it. Vendor: www_boost_org; Tag: boost-1_30_0.
Files on the vendor branch are added, deleted, and "updated".
The trunk is left alone.
I merge the changes in to the trunk:
cvs update -jboost-1_29_0 -jboost-1_30_0
Lot's of files get added, deleted, and updated.
I resolve the merge conflicts. I commit to the trunk.
If I wish to browse the "official" release, I have a poke around branch
What have I missed? What isn't working here that needed this
functionality to be disabled?
This isn't hypothetical - this is what we do with multiple vendor
code sets. Making it so that the vendor changes every time (as well
as the release tag) doesn't seem to add anything apart from another
bit of having to invent a new vendor name for the same vendor for
every release, as well as the release tag. But the vendor *hasn't*
Sorry, I must be being dumb - I just can't see what the change is fixing.
change name before "@" to "phil" for email
More information about the cvsnt