[cvsnt] Merge Philosophy - Request for Comments
diana_chen23 at yahoo.com
Fri Nov 5 20:36:13 GMT 2004
--- Merrill Cornish <merrill.cornish at earthlink.net>
> Your software control process makes me cringe. :-)
> Branching the source and then merging the branch
> back in later is sometimes necessary, but it is
> alway tedious. Your appear to be planning N+1
> tedium with one branch per developer plus an
> integration branch.
> In my experience, you want to reserve branching for
> things that can't be done anyother way, so that most
> of the work is always on the trunk. In your plan,
> _none_ of the day-to-day work is on the trunk.
> Furthermore, the integratoin branch adds yet one
> more level of conflict.
> First, consider the trunk and the integration
> branch. Why keep them separate? You can accomplish
> the same thing with tags.
> When the development gets to the point that it is
> ready for testing, the project manager tags the
> ready-for-testing versions of all the files with a
> well-known tag, such as TEST_RELEASE. Your testing
> people simply extract using that tag rather than
> defaulting to the HEAD. Your testing people don't
> know (and don't care) if there are any later
> revisions of any of the files they extract. They
> get the TEST_RELEASE files and that's that.
> If several iterations of testing are necessary, then
> so be it. Each time the source base is thought to
> be ready for test, the project manager moves the
> TEST_RELEASE tag to the new revisions and tells the
> testing people to do it again.
> When a version finally passing testing, the project
> manager attached a tag, say, RELEASE_xyz, to all
> file revisions currently having the TEST_RELEASE
> Your method apparently allows everyone to always
> work off the HEAD revision of a branch or trunk--but
> that is a small advantage over specifying a checkout
> tag rather than taking the default.
> Now, consider your developer branches. The only
> reason a developer _should_ work on a personal
> branch is if that developer is actually
> experimenting with several alternate solutions and
> doesn't want to mess up any other developers until
> he can decide on which alternative to use--but I
> don't think this is what you are doing.
> In general, each developer should work off the
> trunk. As each feature or bug fix is added, those
> files are committed together back to the trunk. In
> this manner, the trunk incrementally grows toward
> the next release.
> At the same time, each developer should
> periodically (once a day?) update his sandbox so
> that he will see whatever else other developers have
> done. In this way, conflicts are seen early, when
> they are small and much, much easier to correct than
> during massive merges at the bitter end.
Thanks for the reply, Merrill.
You raise interesting questions.
First off, I omitted that this is for a company that
does small, embedded firmware, typically less than
12K. Team sizes are 5 or less, and usually size of 1,
2. I don't think this changes anything - but may for
others providing input.
So do all of your developers modify a lot of the same
files? Is that what is driving the need for constant
merge? If developers modify different files, is a
merge from a developer branch to integration branch
all that hard? It could be my past experience with
large, excrutiatingly partitioned systems is coloring
my thinking. ;)
Your trunk and my integration branch are the same
ideas then, yes? A place where efforts are merged to?
If yes, than you certainly got rid of my integration
merge to trunk. Are you able to provide metrics/diffs
from non-consecutive releases (i.e., from one tag to
another tag, with many merges to trunk in between)?
In your example of TEST_RELEASE, do you mean that you
move the label itself? Or was your example simplified
to make the point. (In your example, the Test dept
would have 2 different piles of code, both from tags
TEST_RELEASE!) I am interpretting your example to say
that you would move the "intent" of the TEST_RELEASE
tag, as in make a TEST_RELEASE_1 tag, make a new tag
TEST_RELEASE_2, etc.). Is this correct? My environment
is a little harsher for proving traceability, and I
suspect moving a tag would not be allowed.
So it looks like you advocate no developer branches.
Hmm. Is my understanding correct then? The developer
gets a version of code in their working directory,
makes changes, tests it, and then merges it back to
the trunk. No branches, right back to the trunk. Do
you need to provide metrics for the effort provided by
each developer (i.e, LOC)? If so, how can this be done
since their merge efforts may be scattered over
several merges to trunk until they are done?
Especially when they take in others' changes from the
trunk into their working directory, too? Can this be
Once last question, do you employ a nightly build to
ensure that all is well with the days' worth of
Thank you for your reply,
Do you Yahoo!?
Check out the new Yahoo! Front Page.
More information about the cvsnt