You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2010/03/30 10:20:35 UTC
Re: Spurious svn:mergeinfo updated on random, untouched files on
minimalistic merge?!
On Tue, Mar 30, 2010 at 11:47 AM, Ben <te...@googlemail.com> wrote:
> Hi! We recently upggraded our svn server to 1.6.5 to enable the usage of the
> svn merge tracking capabilities but failed to use it in more than one project
> due unwanted properties changes set on unchanged files.
>
> This makes it very hard to keep track of the real changes vs. svn internal
> changes.
>
> We always merge the root directories so I'd expect svn:mergeinfo properties to
> occur only on the root directory node. In fact we receive property changes on
> files I'd be totally unaware why that one should differ!
>
> Here is my problem in a simple use case:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1) I created a /branches/1.1.x from /trunk in svn rev #3101
>
> 2) We continued developing on /trunk
>
> 3) Just to tryout the merge tracking feature I merged
> /branches/1.1.x back to /trunk
>
> Actually the branch does contain NO COMMIT at all!
>
>
> Expected result:
> ~~~~~~~~~~~~~~~~
> I'd expect, that I receive exactly one filechange: A svn:mergeinfo
> property update on /trunk which indicates my merge 3101-3110.
>
>
> Actual results:
> ~~~~~~~~~~~~~~~
> Actually the svn:mergeinfo of many (random) file are updated and
> I have absolutley no clue why!
>
> Here is one example:
>
> <empty svn:mergeinfo>
> gets to
>
> /branches/1.1.x/views-xlsexport/src/test/java/setup/export/ExportTest.java:310
> 2-3110
>
> /branches/wss-850_devel/views-xlsexport/src/test/java/setup/export/ExportTest.
> java:2622-2680
>
>
> WTF? That branch "wss-850_devel" even no longer exists!
>
>
> On the parent directories "setup" the situation is similar:
>
> /branches/1.1.x/views-xlsexport/src/main/java/setup:3101-3113*
> /branches/wss-850_devel/views-xlsexport/src/main/java/setup:2622-2680
> /trunk/views-xlsexport/src/main/java/setup:2-2590*
>
> I checked out and ressureceted that expunged branch wss-850_devel
> to check if svn:mergeinfo properties have been defined there.
> Negative.
>
> Questions:
> ~~~~~~~~~~
> So is anybody able to give us a hint or explain what happens and/or what we do
> wrong?
> Or event better: Can anybody gives hints on the technical backgrounds?
>
> - Why do unrelated branches appear in my mergeinfo
> - Do I have wrong expectations that only one file should change?
> - Are svn:merginfos repository global or locally to a revision?
> - What does the /trunk related entry mean?
> I merged the dir to myself? Huh!
> - What does the asterix mean (3101-3113*)
>
> I very appreciate any hint or link to more detailled background information
I don't have time right now to analyze and explain your particular
situation, but as for a link to detailed background information, you
might want to read this article:
http://www.collab.net/community/subversion/articles/merge-info.html
Also, if I understood correctly, improvements are being made in this
area for svn 1.7 (for starters, in 1.7 only subtrees affected by the
merge will have their mergeinfo updated). But it's too early to tell
how that will work out. Svn 1.7 is still at least a couple of months
away...
--
Johan
RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?! -- SOLVED !!!
Posted by Ben <te...@googlemail.com>.
Hi Stanimir!
My problem was:
I did not have any svn:mergeinfo on any subdirectories on merge source
as well on the merge target before doing a merge.
But after doing a merge I received tons of newly added svn:mergeinfo
entries at random files & directories.
I really spent a lot of time to understand and solve this siutation.
Finally it turned out, that during our daily work, the subversion
clients tends to "break" existing working copies. It thinks, that you
have a incomplete working copy at some points in the directory
structure. You can identify these siutation by running svnversion: If it
reports a version other than a single number without any suffixes (M may
be ok) you'll run into issues using svn merge and receive additional
svn:mergeinfos on places other than the root directory.
So my best practice checklist for using svn merge is:
- always merge only on root directories
- make a full svn update on the target prior merging
- assert svnversion reports only one number and NO "p" suffix
- perform the svn merge
Hope this helped to understand my original problem and my final
findings.
Thanks a lot for your support, guys!
Cheers
- Ben
P.S.: The other questions is: how & why do working copies break into
"partial state". But this is propably a differnent topic.
-----Original Message-----
From: Stanimir Stamenkov [mailto:s7an10@netscape.net]
Sent: Wednesday, March 31, 2010 9:05 PM
To: users@subversion.apache.org
Subject: Re: Spurious svn:mergeinfo updated on random, untouched files
on minimalistic merge?! -- SOLVED !!!
Wed, 31 Mar 2010 16:22:37 +0200, /Ben/:
> My problem was not any existing svn:mergeinfos. Neither the source nor
> the target contained *any* svn:mergeinfo except one at the target
root.
> But I finally found the solution!
>
> My problem was:
> *svnversion reported 3128P*
>
> I have no clue how this occured. We *never* do partial chechkouts, but
a
> short poll at my collegues showed, that many of them having this
> situation, too!
>
> After recovering the partial state all works as expected.
Ben, I haven't got what your actual problem was. You've stated you
didn't have svn:mergeinfo on files and folders below the root. What
does "svnversion reported 3128P" mean?
--
Stanimir
Re: Spurious svn:mergeinfo updated on random, untouched files on
minimalistic merge?! -- SOLVED !!!
Posted by Stanimir Stamenkov <s7...@netscape.net>.
Wed, 31 Mar 2010 16:22:37 +0200, /Ben/:
> My problem was not any existing svn:mergeinfos. Neither the source nor
> the target contained *any* svn:mergeinfo except one at the target root.
> But I finally found the solution!
>
> My problem was:
> *svnversion reported 3128P*
>
> I have no clue how this occured. We *never* do partial chechkouts, but a
> short poll at my collegues showed, that many of them having this
> situation, too!
>
> After recovering the partial state all works as expected.
Ben, I haven't got what your actual problem was. You've stated you
didn't have svn:mergeinfo on files and folders below the root. What
does "svnversion reported 3128P" mean?
--
Stanimir
RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?! -- SOLVED !!!
Posted by Ben <te...@googlemail.com>.
Geoff - Thank you very much for your extensive advice of how to avoid
these problems! We'll definitly implement your hint regarding a
subversion hook.
My problem was not any existing svn:mergeinfos. Neither the source nor
the target contained *any* svn:mergeinfo except one at the target root.
But I finally found the solution!
My problem was:
*svnversion reported 3128P*
I have no clue how this occured. We *never* do partial chechkouts, but a
short poll at my collegues showed, that many of them having this
situation, too!
After recovering the partial state all works as expected.
Thanks a lot to everybody for your time and support!
- Ben
-----Original Message-----
From: Geoff Rowell [mailto:geoff.rowell@gmail.com]
Sent: Wednesday, March 31, 2010 2:56 PM
To: 'Ben'
Cc: users@subversion.apache.org
Subject: RE: Spurious svn:mergeinfo updated on random, untouched files
on minimalistic merge?!
In addition to adding merge info to your working copy target, merge info
will be added to any file or folder under a target folder if the file or
folder already has an "svn:mergeinfo" property. This will happen even if
the
original "svn:mergeinfo" property is empty.
The only way to correct this is to consolidate the merge info into the
root
folders of a working copy, and its externals, and to *delete* the
"svn:mergeinfo" property from all child folders and files.
To avoid an increasing number of items with this property, as a result
of
non-root merges or copies, you would have to restrict setting of the
"svn:mergeinfo" property to a root folder.
The Subversion Hook Framework can be used to enforce this policy.
- http://sourceforge.net/projects/svnhook
There's an example of the required configuration (XML) file entry on the
"Hook Configuration File Examples" page of the wiki.
-
http://sourceforge.net/apps/mediawiki/svnhook/index.php?title=Hook_Confi
gura
tion_File_Examples
-Geoff
RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?!
Posted by Geoff Rowell <ge...@gmail.com>.
In addition to adding merge info to your working copy target, merge info
will be added to any file or folder under a target folder if the file or
folder already has an "svn:mergeinfo" property. This will happen even if the
original "svn:mergeinfo" property is empty.
The only way to correct this is to consolidate the merge info into the root
folders of a working copy, and its externals, and to *delete* the
"svn:mergeinfo" property from all child folders and files.
To avoid an increasing number of items with this property, as a result of
non-root merges or copies, you would have to restrict setting of the
"svn:mergeinfo" property to a root folder.
The Subversion Hook Framework can be used to enforce this policy.
- http://sourceforge.net/projects/svnhook
There's an example of the required configuration (XML) file entry on the
"Hook Configuration File Examples" page of the wiki.
-
http://sourceforge.net/apps/mediawiki/svnhook/index.php?title=Hook_Configura
tion_File_Examples
-Geoff
-----Original Message-----
From: Ben [mailto:tebulin@googlemail.com]
Sent: Wednesday, March 31, 2010 7:48 AM
To: users@subversion.apache.org
Subject: RE: Spurious svn:mergeinfo updated on random, untouched files on
minimalistic merge?!
Thank you very much for that helping link!
This is exactly the type of background information I've been looking for.
With the help of your linked article, if found out that on the root
directory
a mergeinfo was set. I tried to removed the existing property as workaround
on
both trunk & branch.
Unfortunately I still receive explicit entries mergeinfo entries following
this scheme on totally unrelated paths (no relevant commit since
branch-off):
Added: svn:mergeinfo
Merged /branches/1.1.x/tools/releasenotes:r3101-3122*
Added: svn:mergeinfo
Merged /branches/1.1.x/tools/releasenotes/axis-jaxrpc-1.3.jar:r3101-3122
Any hint on where those do origin from?
Are those issues adressed by svn 1.7.x?
The mentioned articel did not provide any explanation pattern for me.
Cheers!
- Ben
-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel@gmail.com]
Sent: Tuesday, March 30, 2010 12:21 PM
I don't have time right now to analyze and explain your particular
situation, but as for a link to detailed background information, you
might want to read this article:
http://www.collab.net/community/subversion/articles/merge-info.html
Also, if I understood correctly, improvements are being made in this
area for svn 1.7 (for starters, in 1.7 only subtrees affected by the
merge will have their mergeinfo updated). But it's too early to tell
how that will work out. Svn 1.7 is still at least a couple of months
away...
--
Johan
RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?!
Posted by Ben <te...@googlemail.com>.
Thank you very much for that helping link!
This is exactly the type of background information I've been looking for.
With the help of your linked article, if found out that on the root directory
a mergeinfo was set. I tried to removed the existing property as workaround on
both trunk & branch.
Unfortunately I still receive explicit entries mergeinfo entries following
this scheme on totally unrelated paths (no relevant commit since branch-off):
Added: svn:mergeinfo
Merged /branches/1.1.x/tools/releasenotes:r3101-3122*
Added: svn:mergeinfo
Merged /branches/1.1.x/tools/releasenotes/axis-jaxrpc-1.3.jar:r3101-3122
Any hint on where those do origin from?
Are those issues adressed by svn 1.7.x?
The mentioned articel did not provide any explanation pattern for me.
Cheers!
- Ben
-----Original Message-----
From: Johan Corveleyn [mailto:jcorvel@gmail.com]
Sent: Tuesday, March 30, 2010 12:21 PM
I don't have time right now to analyze and explain your particular
situation, but as for a link to detailed background information, you
might want to read this article:
http://www.collab.net/community/subversion/articles/merge-info.html
Also, if I understood correctly, improvements are being made in this
area for svn 1.7 (for starters, in 1.7 only subtrees affected by the
merge will have their mergeinfo updated). But it's too early to tell
how that will work out. Svn 1.7 is still at least a couple of months
away...
--
Johan