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

Re: Revert semantics after a merge in working copy

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 29 Apr 2008 07:27:29 -0400

Leonardo Fernandes wrote:
> Hi.
> After merging some changes in a working copy, we sometimes need to redo
> the merge, or just delay the merge, in some files. Our first instinct is
> to revert the single file, and repeat the merge. But it doesn’t work as
> expected, because of the ancestry lookup for mergeinfo.
> That’s ok, and I know there exists an option to ignore the ancestry,
> which is what we do right now. My only question is, shouldn’t the revert
> record the merge was reverted in those files? Because the current
> semantics are the same as “accept mine as merge result”, which is a bit
> confusing.

When you say "revert", I assume you are talking about "reverse merge" ('svn
merge -c -N ...'), not 'svn revert ...'.

Oh! Now that I think about what you are seeing, maybe you're *not* talking
about that. And maybe that's the solution. Rather than reverting the files
you wish not to yet merge, just reverse the merge operation on them (either
by literally reversing the merge for those files, or by reverting them and
then doing a --record-only reverse merge). That will cause those files to
no longer claim to have received the original merge, which then allows them
to be candidates to receive their portions of that original merge if you
later repeat that merge.

(Oh. And this question is better aimed at users@, since it doesn't related
to the development of Subversion itself.)

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-04-29 13:27:53 CEST

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.