On Thu, Oct 28, 2010 at 4:40 PM, Wöster Benjamin <[email protected]> wrote: > Hi all, > > > > I’m currently trying to clean up explicit mergeinfos that are scattered > throughout our repository. > > Some of these explicit mergeinfos were created because people used sparse > working copies and didn’t know about the impacts. > > So I’m trying to locate the pathes that contain non-inheritable mergeinfos, > check that those merged revisions didn’t affect the children of that path, > > and redo the merge with the –record-only option for that path. This way, I > hope I can eliminate the non-inheritable mergeinfos as first step of the > cleanup. > > > > I’ve attached a perl script, that will reproduce a sample environment (it > needs svn and svnadmin to be in your path). > > It creates (in your current working directory) a repository and a working > copy. The script creates some test data, creates a feature branch, > > simulates some work (including cherry-picking from trunk to the feature > branch) and at the end, it merges the branch back to the trunk. > > Last but not least, it creates a cleanup branch. > > > > > > This is the point where I am with my productive repository, and it turns > out, that the cherry-picked revisions cause the behavior I wouldn’t have > expected. > > The following is the session I use to reproduce the work till the point > where I’m unsure if svn does things right. > > > > # creating the test data > > c:\mergeinfo>mergeinfo_fixture.pl > > c:\mergeinfo>dir > > Verzeichnis von c:\mergeinfo > > > > 28.10.2010 20:33 <DIR> . > > 28.10.2010 20:33 <DIR> .. > > 28.10.2010 20:28 2.108 mergeinfo_fixture.pl > > 28.10.2010 20:33 <DIR> repo > > 28.10.2010 20:33 <DIR> wc > > > > # navigate to the cleanup branch > > c:\mergeinfo>cd wc\branches\cleanup > > > > # checking for the non-inheritable merge info > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 > > /branches/feat_1/folder_1:2-6* > > /trunk/folder_1:4* > > > > So here it is. My understanding of the mergeinfo and the mergeinfo elision > is, that once these revisions get merged into the children of that path, > > the explicit merge info should disappear. So I’m trying: > > > > > > (first with svn 1.6.12, which behaves the way I expected it to work) > > > > c:\mergeinfo\wc\branches\cleanup>svn –version > > svn, version 1.6.12 (r955767) > > > > c:\mergeinfo\wc\branches\cleanup>svn merge -r 3:4 --record-only > "^/trunk/folder_1" folder_1 > > c:\mergeinfo\wc\branches\cleanup>svn status > > M folder_1 > > > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 > > /branches/feat_1/folder_1:2-6* > > /trunk/folder_1:4 > > > > So we see: r4 is no longer been marked as non-inheritable, but since it > still contains other non-inheritable mergeinfos, > > the data is still stored as explicit mergeinfo. I’m fine with that. > > > > > > (now the same with the newer svn 1.6.13) > > > > c:\mergeinfo\wc\branches\cleanup>svn revert . -R > > Reverted 'folder_1' > > > > c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe" > --version > > svn, Version 1.6.13 (r1002816) > > > > c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe" > merge -r 3:4 --record-only "^/trunk/folder_1" folder_1 > > c:\mergeinfo\wc\branches\cleanup>svn status > > M folder_1\file_1 > > M folder_1\file_2 > > M folder_1\file_3 > > > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 -R > > folder_1\file_1 - > > folder_1 - /branches/feat_1/folder_1:2-6* > > /trunk/folder_1:4* > > folder_1\file_2 - > > folder_1\file_3 – > > > > Now, this is what I don’t understand. I merged (well, recorded) the changes > of revision 4 into a fully recursive working copy. > > The result according to the new client is, that the revision was only merged > down to folder_1, not into its children. > > Those instead get an explicit, empty mergeinfo property set, which means: > “Nothing has been merged to me so far”. > > > > I’m unsure if this behavior is intended. It’s correct that none of the > changes would have ever touched those files, > > but didn’t I tell svn to record that the revisions should be marked as > merged? In my opinion, it simply refuses to do that (the 4* still exists), > > plus it adds more explicit mergeinfo to the childs (something I can’t > understand right now, but maybe it makes sense). > > > > So what do you think? Is this behavior intended or did something go wrong > between v1.6.12 and 1.6.13? > > Or maybe am I missing some important point? > > > > Thanks in advance!
The asterisk at the end of the revision number list indicates that the revision list only applies to the current directory - i.e. it's non-recursive. BTW, I posted a similar Perl script to this mailing list some time ago. When done, you may want to look into the Subversion Hook Framework for a hook script that prevents recording merge into for lower level files and folders. -- Geoff Rowell [email protected]
