> -----Ursprüngliche Nachricht----- > Von: Geoff Rowell [mailto:geoff.row...@gmail.com] > Gesendet: Freitag, 29. Oktober 2010 18:33 > An: Wöster Benjamin > Cc: users@subversion.apache.org > Betreff: Re: unexpected mergeinfo results (v1.6.13) > > On Thu, Oct 28, 2010 at 4:40 PM, Wöster Benjamin <b.woes...@cadenas.de> > 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.
[Benjamin Wöster] That's exactly my point. In the example above, r4 has been marked as "merged only into branches/cleanup/folder_1, not into its children". Then, I explicitly tell svn to merge the revision into the children of that folder, in the hope that this resolves the non-inheritable mergeinfo. Client 1.6.12 does what I expect it to do, but the newer one does weird things. So I wonder if this is a bug introduced in 1.6.13? > > 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. [Benjamin Wöster] Thanks for the hint, I'll have a look. Might come in handy. > -- > Geoff Rowell > geoff.row...@gmail.com
