Date: Sat, 19 Apr 1997 17:26:14 +0200 (MET DST) From: Eivind Eklund <eivind@nic.follonett.no> To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org Subject: Re: CVS vendor branches Message-ID: <199704191526.RAA26899@nic.follonett.no> In-Reply-To: <199704182251.PAA03213@phaeton.artisoft.com> from Terry Lambert at "Apr 18, 97 03:51:31 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > a way of hacking some of the wanted
> > features is by treatingthe FreeBSD main development as a vendor
> > branch, and using cvs import to maintain the parts you don't change.
>
> This works, but then I have my history at the cost of losing that
> of FreeBSD. It also leaves the issue of integrating my history
> blowing in the wind... when/if an integration takes place, the
> only thing imported will be my tip, right? So if I do something to
> accommodat a VM bug (say), and it's later fixed, and I want to
> branch back there for maintenance, now you must resolve conflicting
> tips, right?
Not nescessarily. I have some ideas for how to create a fake branch at your
machine, and then importing the branch into the FreeBSD CVS repository _as a
branch_ at a later date.
(1) You work on a CVS-tree with FreeBSD-current imported as a base. Any
conflicting changes to the tree done by the main FreeBSD development
line, you merge. (This is less work than it sound like). When you're
done, you end up with one large patch which will bring
-CURRENT to be equal to your source (or the relevant parts of it).
You submit this as a script, a script which also recreate your
changes as a branch of the FreeBSD CVS tree.
This way, your editing history will be recorded in a branch, and the tip
of that branch will be integrated as YAMFT with a reference to your
branch for editing history. At this point, you abandon your changes to
the imported source, as your changes have been brought into the main
tree. (The abandoning can be done by re-creating the underlying CVS/RCS
files of just those files, if nescessary re-creating any later patches.
This can be automated.)
If you are doing further development, you create another branch.
Diskspace requirements: This model would require a FreeBSD CVS tree kept
up to date, a copy of the FreeBSD source tree used as an import base, a
local CVS tree with the imported sources, and a checked out copy of the
FreeBSD sources with your changes from the local CVS tree.
(2) This could probably also be done by creating a copy of the FreeBSD CVS
tree with a "Terry" branch in it. You would need to create a local copy
of the FreeBSD CVS tree, branch it, and make scripts to keep the head up
to date with regards to a clean copy. It is possible that all of this
could be done from the CTM delta files.
Integration of your changes and edit-history would have to be done in
the same way as suggestion (1).
Benefits of (1) is that it is least work to implement; benefits of (2) is
that it is probably most comfortable to work with.
Does the above suggestions sound like it could create a tolerable
working-environment?
As for the 'ideal environment' section:
I'm having a difficult time envisioning how your 'unbranching' would work;
any changes will need to be merged by a human at some point, and I can't see
how unbranching would work differently from the present branches, except
that they presumably have a machine-readable tag pointing back from the
merge-point, and are frozen at merge. This sound technically sound, but not
really nescessary. Am I missing something?
Having CVSup/CTM automatically create and rename branches sound nice; I
wonder how much work it would be to implement. However, just having them
respect branches would probably be enough; the problem is how to do this and
still keep CVSup as rock-solid as it is towards partial or damaged
CVS-trees.
regards,
Eivind.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704191526.RAA26899>