You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Leonardo Fernandes <le...@outsystems.com> on 2008/04/29 10:51:31 UTC

Revert semantics after a merge in working copy

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.

 

Thanks,

Leonardo Fernandes


Re: Revert semantics after a merge in working copy

Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand