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