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