> You need to compare /branch@(Y+1) with /branch@HEAD.
That's not right, it will miss any @Y to @(Y+1) change. If
the first merge is @X to @Y, the next merge should be @Y to
@Z.
It gets more complicated/"fun" if you also:
(a) merge back and forth between trunk and branch
(b) take uncommitted changes in the working directory into account
(c) care about adjusting the relative priorities of the three
sets of changes in play (trunk, branch, and wd) [*]
For extra fun, throw in:
(d) over time, you alternate between cherry-picking and full merging
between trunk and branch
Step (a) makes it trickier to identify the appropriate
baselines to compare.
Steps (b) and (c), taken together, give you multiple different merge
techniques to choose from.
All steps, though (d) makes it really obvious, suggest strongly that
you want ultimately to automate bookkeeping of the merge history of
"whole project trees" -- not just individual files and directories.
This is a _little_ tricky to reconcile with svn's project-less model
and support for "mixed revision" working directories.
One big weakness I see here for svn is bookkeeping. My understanding
is that it's up to users to keep track of or figure out the revision
numbers that are relevant to project merging. Given all those numbers
and a map of the history of past merges, it's just a few minutes of a
casual puzzle to figure out the right combination of `co', `merge',
and `switch' commands to do an "intelligent, history-sensitive merge"
-- but keeping or figuring out those numbers and that merge history is
less trivial. It doesn't help that svn rev ids are global rather than
sequentially allocated per development line -- so, after a few years,
my corporate repository is presumably going to have 6-digit ids and so
forth -- and good luck building a nice graphical map of the merge
histories of my various project branches.
So, personally, I think it makes sense to keep that "whole project"
merge history automatically. It _can_ be done without deep changes to
svn itself -- i.e., it can be regarded as a layer over svn. Among the
payoffs of that approach is that it can buy a useful form of
distributed repositories for not-quite-free-but-cheap (i.e., by
recording that history in a repository-neutral way).
-t
[*] "adjusting the relative priorities of changes" means, for example,
regardless of where you are going to commit: are you starting with a
trunk tree and applying patches? or starting with a branch tree?
What might those priorities matter? Well, for example, let's suppose
that trunk is merging back and forth from _multiple_ branches. On a
previous merge from trunk into branch, a bunch of conflicts were
resolved in favor of the version on branch (because, say, trunk and
branch had made conflicting API changes -- or branch had decided to
not yet pick up an API change merged into trunk from elsewhere). At a
later date, branch is ready to pick up that API change. If you start
with a trunk tree and patch it for changes on branch, you get just a
few conflicts -- if you start with a branch tree and patch it for
changes on trunk, you get many conflicts. (This isn't theoretical --
I've actually experienced this conflict differential in bidirectional
merges.)
A second reason priorities matter is if you switch from
conflict-marker to .rej-style conflict resolution -- which tree's
changes get shoved off into .rej and which are in the source?
Personally, I find the .rej style often more convenient -- but that
has as much to do with my personal emacs habits as anything else.
Other people are presumably have the opposite experience. (In
particular, I've found it easy to go through and look at ".rej" files
and then just delete them because I know they're not important --
that's easier than editing the corresponding files, finding the
conflict markers, deleting the markers, and deleting the correct one
of the two alternatives.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 01:08:40 2003