subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wöster Benjamin <B.Woes...@cadenas.de>
Subject unexpected mergeinfo results (v1.6.13)
Date Thu, 28 Oct 2010 20:40:28 GMT
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!

Greetings,
Ben

Mime
View raw message