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

RE: subtree merge

From: Bob Archer <bob.archer_at_amsi.com>
Date: Tue, 6 Oct 2009 11:33:36 -0400

> 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/play
> er.html
> > G
> ZV/ZV_Viewer/extensions/mediaplayers_at_zeevee.com/chrome/content/vlc/play
> er.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. :(
>

I think the G means that it was updated and was M when the merge happend. I think this can happen if you have a broken range of revision to merge which both modify the same file. The first merge will change the status to U then the second to G.

BOb

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2404154

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-06 17:35:20 CEST

This is an archived mail posted to the Subversion Users mailing list.