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

[Mark D. Baushke]

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

Greg A. Woods <address@hidden> writes:

> [ 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.

Use of the 'cvs import -X' on the cvs 1.12.10 (not yet released) deals
with many of these problems.
 
> 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.

Again, this is being addressed by the 'cvs import -X' option which
creates a dead version 1.2 on initial import.

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

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBl9ef3x41pRYZE/gRAqzBAJ0b7wIAxF2oCx/BeKNS/1KIjh66xACg19aE
1GkfpXGRfSOAOjELRAWhHfQ=
=bbJC
-----END PGP SIGNATURE-----