Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Bo Berglund wrote:
> Just to clarify for my understanding I quote from Cederquist:
> With two `-j' options, merge changes from the revision specified with
> the first `-j' option to the revision specified with the second `j'
> option, into the working directory.
[...]
> Now what I want to make sure is that -jHEAD -jBranch will result in a
> sandbox HEAD file that is exactly like the one on the Branch tip,
> ready for commit. Is this how it works?
Yup - indeed it does. The changes from HEAD to Branch are precisely those
required to bring your local sandbox containing the HEAD revision in
sync with what is on Branch. (Think of it as generating a patchfile
from HEAD to Branch, and then applying the patchfile to HEAD... that's
how I end up having to explain to the ex-Visual Source Safe users :-)
WARNING: there is an implicit assumption here that no-one is changing the
mainline underneath you. We handle this by having a physical lock that
has exclusive ownership. (Could be done via CVS with locked files and
scripting stuff, I suspect, but ours is a small furry toy.)
> Note that I am not after *merging* the Branch in because I have tried
> that and it invariably causes a lot of conflicts. Instead I want to
> promote Branch to the new HEAD completely discarding what is in HEAD.
And that is what will happen. We use this "feature" all the time
(we do lots of merges from mainline to branch, and so when we are
"merging" back down we actually are replacing the mainline with the
contents of the branch - which has already had the current mainline
merged in *it*).
Now, if the mergepoint processing could handle the merge from
branch-to-mainline as well as all the mainline-to-branch merges we do,
I'd be a very happy man :-) ('cos we'd then have a clear indication on
the mainline about which branch delivered every revision).
(I have an "on paper" algorithm for supporting this, but don't have the
time at the moment to get a working "proof of concept" - it theory, it
should support multiple, interleaved, merges between mainline and a
branch - but not anything *too* complicated.)
phil
--
change "spam"/"news" to "phil" to email me