On Mon, Oct 05, 2009 at 08:38:30PM -0400, Jeremy Mordkoff wrote:
> Another developer was working in a project branch and merged to trunk,
> but he did the merge in the subdirectory 'ZV'. so now I have
>
> [release_at_zaz1 trunk]$ svn pg svn:mergeinfo .
> /zcode/branches/es_zvb_reset:9521-9652
> /zcode/branches/rel_2_1:8309-9633
> /zcode/branches/rel_2_2:9342-9705
> /zcode/branches/rel_2_2_1:9697-9706
>
> [release_at_zaz1 trunk]$ svn pg svn:mergeinfo ZV
> /zcode/branches/online/ZV:9220-9713
>
> Does this mean that the merge history for '.' will now be ignored when
> I'm merging 'ZV'? It does appear that way, because when I merged
No. As I understand it, the merge process will first look at the
mergeinfo on ZV and then also look at the mergeinfo for anything above
ZV (in your case, it will find the mergeinfo for trunk).
> [release_at_zaz1 trunk]$ svn merge $SVN/branches/rel_2_2_1
> --- Merging r9698 through r9709 into 'ZV':
> G ZV/ZV_Viewer/extensions/mediaplayers_at_zeevee.com/chrome/content/vlc/player.html
> G ZV/ZV_Viewer/extensions/mediaplayers_at_zeevee.com/chrome/content/vlc/player.xul
> G ZV/ZV_Viewer/extensions/mediaplayers_at_zeevee.com/chrome/content/vlc/main.xul
> ...
> G ZV/plugins/mozilla_remote
> --- Merging r9711 through r9715 into '.':
> U lcast/components/cli/src/CliSet.cxx
> U lcast/components/mpeg2/src/mpeg_ts.c
> G .
> [release_at_zaz1 trunk]$
> [release_at_zaz1 trunk]$ svn status
> M .
> M ZV
> M lcast/components/cli/src/CliSet.cxx
> M lcast/components/mpeg2/src/mpeg_ts.c
>
>
> Is this to be expected? What do all the 'G's mean? Merged, right? But
> then there's no changes...so what was merged?
I don't know why all those Gs show up. They look like they're in the
second column, which is not documented in svn help status nor in svn
help merge. :(
> Besides forcing all merges to be done from the top (which is probably
> not reasonable), is there a way to clean this up? Could I just move
> the svn:mergeinfo entry from 'ZV' to the root if I am sure no other
> subdirectories had ANY changes in that project branch? Or is there an
Forcing all merges to be done from the top of the tree is perfectly
reasonable. That's how we do it. There is no other way to prevent the
creation of unwanted subtree mergeinfo.
I just went through this yesterday and the solutions we dreamed up were:
1. (most "correct") Roll back the bad merge, do it again from the top of
the tree, done.
2. (arguably faster/simpler, but probably more confusing, especially if
you get it wrong and try to postmortem it later) Perform a --record-only
merge of the same revisions at the top of the tree; delete the mergeinfo
from the subtree.
> apologies if this goes out in HTML format.
No HTML here, but lines weren't wrapped properly (I think 72 characters
is the lingua franca of the internets).
tyler
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2404142
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-06 17:21:08 CEST