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

subtree merge

From: Jeremy Mordkoff <jlm_at_ZeeVee.Com>
Date: Mon, 5 Oct 2009 20:38:30 -0400

Another newbie question

I have 9 major components in my code base, each with its own subdir at the top. I have been doing all of my merges from the top. So far so good.

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 .

[release_at_zaz1 trunk]$ svn pg svn:mergeinfo ZV

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 everything from rel_2_2_1 to trunk I got a couple hundred 'G' notices for files under ZV, but when all was said and done, svn diff said nothing had changed under 'ZV':

BTW 9697 is the revision that was copied to make branch rel_2_2_1 and 9709 is the tip of that same branch, but there are NO changes in this subdir in this branch.

[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 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?

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 option to say ignore svn:mergeinfo entries in subdirectories? ... hmm...that feels like a 'bad idea'

In the end, it does appear that svn did the 'right thing' but I've already reverted these files because this has me worried.

Thanks for the help on my last question
Thanks in advance for any help on this one
apologies if this goes out in HTML format.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-06 02:39:22 CEST

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