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
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
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
This is an archived mail posted to the Subversion Users mailing list.