info-cvs
[Top][All Lists]
Advanced

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

Re: Problem with importing third-party sources and adding/committing cha


From: Greg A. Woods
Subject: Re: Problem with importing third-party sources and adding/committing changes
Date: Sun, 14 Nov 2004 13:53:08 -0500 (EST)

[ On , November 12, 2004 at 15:36:39 (-0800), Allen Sturtevant wrote: ]
> Subject: Re: Problem with importing third-party sources and adding/committing 
> changes
>
>      Thank you for this additional info.  I wanted
> to do something similar to this, but I'm just
> now realizing that maybe CVS doesn't work the way
> I had hoped.  I want to "live" in the branches,
> not in the trunk.

It's much deeper than that.

CVS also won't work very well for you when you try to mix the use of
normal CVS branches in a magic vendor-branched module to which you
continue to import new vendor releases.

The magic CVS vendor branch, and the way "cvs import" works, and
especially the nasty trick it uses with the RCS default branch, all
together does not mix very well with normal CVS branches, especially
when a normal branch becomes rooted simultaneously on both the trunk (or
some other normal branch) and the vendor branch.

Note also that the primary (mis)feature of "cvs import" is/was to
automatically detect local conflicts before merging them.  Sadly this
doesn't have the desired effect even with standard vendor-branched
modules since they're almost always put immediately into an inconsistent
state as the "cvs import" begins.  Even ignoring that drawback there's
still the fact that this conflict detection only works if _all_ of the
local changes are on the trunk.

If you _really_ want to use branches to keep track of local bug fixes to
third party projects then I would VERY STRONGLY suggest that you treat
the vendor as a normal local developer who only ever works on some
specific branch.  I.e. assign the duties of the vendor to some local
developer who will "wear the vendor's hat for a day" so to speak and
commit each new vendor release to your repository on the vendor's behalf
in the same way as if the vendor was working directly in your
repository.

It's just that the resolution of the vendor's commits will be once per
release, not once per change.  :-)

You could have the vendor always commit directly to the trunk, or you
could create a special branch that only the vendor commits to.

Given what you say the former might work well for you, but it goes
against the most common normal pattern of CVS usage where local users
primarily work on the trunk and where releases are created on branches.
I.e. the former will create a situation where it is easy for local users
to make the mistake of committing local changes to the trunk whereas
only the new vendor releases should ever be committed to trunk.

However in the latter case the merging of new vendor releases from the
normal branch created for the vendor to work on, onto each of the local
working branches (e.g. to populate local bug fixes to new releases), may
be a _lot_ more work and somewhat more complex to manage since _a_
common normal paradigm for using CVS is to create branches from the
trunk (and perhaps merge changes from now-frozen branches to these new
branches in order to, for example, move feature changes from one release
to another).  This problem might be eased somewhat though if you always
keep a local baseline release on the trunk and you only ever use
branches to create change-sets of local fixes and each changeset is
merged to the trunk so that they can all be merged just once with new
vendor releases and then once merged and committed to the trunk only new
change-set branches will be created for new changes to the new release.


If you want to use the magic CVS vendor branch and "cvs import" in the
way it works best then you must avoid creating local branches (which
means you must mix all your local changes with each other on the trunk)
and live with the fact that after each "cvs import" there will be a
period of instability until the vendor changes are merged to the trunk
and successfully committed.


You might get away with using "cvs import" if you _never_ check out the
trunk or commit to it but _always_ manually merge vendor releases to
other local normal branches.  However this is just as much work as using
a private normal branch for the vendor and more work than having the
vendor commit to the trunk.

Alternatively You might get away with using "cvs import" if you have
initially committed some local (but perhaps innocuous and easy-to-merge)
change to _every_ file on the trunk and have done so _BEFORE_ you ever
create any local branches and only if you _always_ create branches from
the trunk or from other normal branches and _never_ branch from the
magic vendor branch.  However this is just as much work as using a
private normal branch for the vendor and more work than having the
vendor commit to the trunk.

-- 
                                                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]