Subject: advanced usage advice: the prism technique
Newsgroups: gmane.comp.version-control.arch.user
Date: 2003-07-18 08:10:51 GMT (5 years, 50 weeks, 3 days, 8 hours and 50 minutes ago)
I'm partly repeating myself, but now with more experience.
This is proving to be a _really_ nice arrangement of development lines
for a programmer working on several things at once. I'm sure it also
generalizes beyond individual programmers, as well:
key:
a <-> b a and b star-merge back and forth
a <~>> b a "prism merges" into b
pure versions
-------------
| < ~~~~ >> feature a <---> |
| |
working | < ~~~~ >> feature b <---> | mainline
| .... |
| < ~~~~ >> global c <---> |
What does "prism merge" mean, as in "working prism merges into feature
b"?
It means that instead of committing directly to "working", I commit in a
few steps:
1) make some changes to working
2) decide which of the pure versions those changes belong on.
Call my project-tree for this version $PURE_TREE and its version $PURE.
3) in my project-tree for working, run:
tla what-changed -o ,changes [--diffs]
4) mv ,changes $PURE_TREE
5) pushd $PURE_TREE
6) tla redo -p ,changes
7) tla commit
8) popd
9) tla sync-tree $PURE
10) tla commit
When the changes accumulated on a particular pure version hit a
milestone:
1) cd $PURE_TREE
2) [if not up-to-date with mainline]
tla star-merge mainline .
tla commit
3) cd $MAINLINE_TREE
4) tla star-merge $PURE .
tla commit
Sometimes, then, I'll want to repeat steps (1) and (2) on other pure
versions, depending on the nature of what's just been merged into
mainline.
The net effect:
"working" evolves chaotically -- lots of commits which are incremental
progress on this or that.
The pure versions accumulate thematically related changes, in
isolation.
The mainline is only ever modified by clean, isolated, changesets.
_Obviously_ it's possible to get into a situation where interference
between the various pure branches complicates the merges in that
graph. A partial (and for me, so far, quite effective) way to deal
with that is the pure version I labled "global c" -- it's for changes
that I then want to "broadcast" to some or all of the other pure
versions -- for example, to make sure they can keep smoothly
prism-merging from working.
Part of what makes this so incredibly smooth and effective for me is
that my revision library is perpetually up-to-date. It's updated on
every commit -- there's one line in my hooks file that ensures that.
Otherwise, the scripts above would be painfully slow.
-t