[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Question regarding merging branches

From: Jon Watte <hplus_at_mindcontrol.org>
Date: 2002-09-10 04:31:32 CEST

If you don't care about hearing how Perforce does merges, which I
feel works smoother than CVS, then stop here.

> It seems that this kind of patching will generate bugs because it is
> "piecemeal". ie. parts of the file get updated because there's no
> clash, and
> other parts don't because there is. However, the parts that do
> get updated
> might rely on the changes in the clashing parts. (as they are all in the
> same file)

FWIW: when resolving merges, Perforce has the option of "-as" for
"accept safe" (only accept changes to files that only one source has
touched), and "-am" for "accept merged" (accept the piece-by-piece
merge for files where that won't generate conflicts). If there's any
conflict, you can choose interactive edit/resolve, postponing the
resolve until later, or accept a "merge" that inserts conflict
markers containing original, "theirs" and "yours" sections for each
conflict, in-line in the source.

(The default is to ask interactively about each needed merge; you
can argue about whether this is the right thing or not)

I find this works very well. You could do worse than cribbing this :-)

> I understand that no data gets lost, but when merging a branch with, say,
> 100 files or more, all of which have committed changes, some conflicting,
> some not, I end up with no idea what's been merged and what hasn't. This
> seems very error-prone.

Perforce also has the notion of "integrate" (scheduling the work) and
"resolve" (figuring out what to do about each file) as a separate task,
and you can't submit with pending un-resolved integrates. This also
seems to work well, and mimicry ought to be considered :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 10 04:33:31 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.