> -----Ursprüngliche Nachricht-----
> Von: Geoff Rowell [mailto:geoff.rowell_at_gmail.com]
> Gesendet: Freitag, 29. Oktober 2010 18:33
> An: Wöster Benjamin
> Cc: users_at_subversion.apache.org
> Betreff: Re: unexpected mergeinfo results (v1.6.13)
>
> On Thu, Oct 28, 2010 at 4:40 PM, Wöster Benjamin <B.Woester_at_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.rowell_at_gmail.com
Received on 2010-11-02 13:47:14 CET