You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andreas Ländle <al...@soloplan.de> on 2010/01/14 14:52:09 UTC
Problem with merge tracking information in conjunction with file externals
Hello,
I discovered an imperfection of subversion 1.6.6 (at least in my eyes) last days when I was merging some files from our trunk into the stable branch.
All the merge tracking information of all files in one directory have been changed.
The detailed situation was the following.
/ (added svn:mergeinfo /trunk:r4)
/directory1 (added svn:mergeinfo /trunk/directory1:r4*)
/directory1/file1 (added svn:mergeinfo /trunk/directory1/file1:r4)
Take into account that file1 represents a few dozen files in the 'directory1'-directory (all with the same 'r4'-mergeinfo).
In my eyes the merge information for /directory1 and the files in it is redundant.
Shouldn't 'Mergeinfo Elision' consolidate the merge-tracking information down to the "root"?
Is this behavior correct? Or have I found a bug or at least an imperfection in subversion?
I have attached a batch script (see below) that reproduces the issue - or at least it should illustrate what I was doing.
How can I avoid the creation of this bunch of merge tracking information during the merge?
Surely, I can revert the merge-information on directory1 before committing my merges (but that seems to be very inconvenient).
Thanks in advance for any hint.
Best regards,
Andreas Ländle
rem create test environment
rmdir TestSvnMerge /S /Q
mkdir TestSvnMerge
cd TestSvnMerge
svnadmin create repos
mkdir project
mkdir project\trunk
mkdir project\trunk\a
mkdir project\trunk\b
echo "EXTERNAL" > project\trunk\b\content.txt
echo "FILE" > project\trunk\a\file1.txt
echo "FILE" > project\trunk\a\file2.txt
svn import project file:///testsvnmerge/repos -m "Import"
rmdir project /S /Q
rem co trunk & create external
svn co file:///testsvnmerge/repos/trunk trunk-wc
svn propset svn:externals "../b/content.txt content.txt" trunk-wc\a
svn ci trunk-wc -m "Added external"
svn update trunk-wc
rem create branch
svn copy file:///testsvnmerge/repos/trunk file:///testsvnmerge/repos/branch -m "Created branch"
svn co file:///testsvnmerge/repos/branch branch-wc
rem edit file (in trunk)
echo "FILE1" > trunk-wc\a\file1.txt
svn ci trunk-wc -m "Edited file"
rem merge from trunk in branch
svn merge -r 3:4 trunk-wc branch-wc
rem visualize the problem
svn diff branch-wc
svn status branch-wc
cd..
**************************************************************************
Soloplan GmbH
Software für Logistik und Planung
Andreas Ländle
Entwicklung
Burgstraße 20 | 87435 Kempten | Deutschland
Telefon: +49 831 57407-465 | Telefax: +49 831 57407-111
E-Mail: al@soloplan.de <ma...@soloplan.de> | Web: www.soloplan.de <http://www.soloplan.de/>
Geschäftsführer: Wolfgang Heidl, HRB 5304 Kempten
AW: Problem with merge tracking information in conjunction with file externals
Posted by Andreas Ländle <al...@soloplan.de>.
Hello Bob,
thanks for the quick answer. It's safe to assume that the published mergeinfo paths are the only merge information on those folders/files.
And of course - if I didn't include the external then the problem doesn't emerge.
Andreas
-----Ursprüngliche Nachricht-----
Von: Bob Archer [mailto:Bob.Archer@amsi.com]
Gesendet: Donnerstag, 14. Januar 2010 16:00
An: Andreas Ländle; users@subversion.apache.org
Betreff: RE: Problem with merge tracking information in conjunction with file externals
> I discovered an imperfection of subversion 1.6.6 (at least in my eyes)
> last days when I was merging some files from our trunk into the stable
> branch.
> All the merge tracking information of all files in one directory have been
> changed.
> The detailed situation was the following.
> / (added svn:mergeinfo /trunk:r4)
> /directory1 (added svn:mergeinfo /trunk/directory1:r4*)
> /directory1/file1 (added svn:mergeinfo /trunk/directory1/file1:r4)
>
> Take into account that file1 represents a few dozen files in the
> 'directory1'-directory (all with the same 'r4'-mergeinfo).
> In my eyes the merge information for /directory1 and the files in it is
> redundant.
> Shouldn't 'Mergeinfo Elision' consolidate the merge-tracking information
> down to the "root"?
This really depends on what other merge info is there. I assume those are not the only mergeinfo paths on those folders/files.
>
> Is this behavior correct? Or have I found a bug or at least an
> imperfection in subversion?
It is possible. I have heard people say that superfluous merge info is created when using externals. Have you tried your script without it containing externals?
> I have attached a batch script (see below) that reproduces the issue - or
> at least it should illustrate what I was doing.
>
> How can I avoid the creation of this bunch of merge tracking information
> during the merge?
> Surely, I can revert the merge-information on directory1 before committing
> my merges (but that seems to be very inconvenient).
Yes, that should be ok, assuming there is no other mergeinfo on that folder/files.
BOb
<script snipped>
RE: Problem with merge tracking information in conjunction with
file externals
Posted by Bob Archer <Bo...@amsi.com>.
> I discovered an imperfection of subversion 1.6.6 (at least in my eyes)
> last days when I was merging some files from our trunk into the stable
> branch.
> All the merge tracking information of all files in one directory have been
> changed.
> The detailed situation was the following.
> / (added svn:mergeinfo /trunk:r4)
> /directory1 (added svn:mergeinfo /trunk/directory1:r4*)
> /directory1/file1 (added svn:mergeinfo /trunk/directory1/file1:r4)
>
> Take into account that file1 represents a few dozen files in the
> 'directory1'-directory (all with the same 'r4'-mergeinfo).
> In my eyes the merge information for /directory1 and the files in it is
> redundant.
> Shouldn't 'Mergeinfo Elision' consolidate the merge-tracking information
> down to the "root"?
This really depends on what other merge info is there. I assume those are not the only mergeinfo paths on those folders/files.
>
> Is this behavior correct? Or have I found a bug or at least an
> imperfection in subversion?
It is possible. I have heard people say that superfluous merge info is created when using externals. Have you tried your script without it containing externals?
> I have attached a batch script (see below) that reproduces the issue - or
> at least it should illustrate what I was doing.
>
> How can I avoid the creation of this bunch of merge tracking information
> during the merge?
> Surely, I can revert the merge-information on directory1 before committing
> my merges (but that seems to be very inconvenient).
Yes, that should be ok, assuming there is no other mergeinfo on that folder/files.
BOb
<script snipped>