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.
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
geoff.rowell_at_gmail.com
Received on 2010-10-29 18:33:31 CEST