svn rename adds mergeinfo property / renaming in working copy does not

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

svn rename adds mergeinfo property / renaming in working copy does not

Nicolai Scheer-3
Hi all,

I just stumbled across a very strange behaviour.
We're using a pre-commit hook, that checks if a commit involves a merge operation.
If the operation does involve a merge, we force the user to use the word "merge" in the commit message.

I implented this using

svnlook diff --no-diff-deleted --no-diff-added -t XXXXXX /my/path/to/repo

and analysing if the string "Added: svn:mergeinfo" or "Modified: svn:mergeinfo" shows up in the diff.

Recently one of my team members tried to rename a sub folder in a project where there is a mergeinfo-property on the base folder.
He tried to do so using the command line client:

svn rename https://example.org/repo/project_a/subfolder_a https://example.org/repo/project_a/subfolder_b

In this example, the "project_a" folder carries the mergeinfo property.

The commit hook complains that the operation is a merge an blocks (the user did not use the word "merge" in the message since the operation is no merge at all).

Doing the same rename in a working copy works.

I was not able to find any documentation on that behaviour: Obviously svn copies the mergeinfo property from the root folder to the renamed folder - but does only so if the rename is invoked as "svn rename from_url to_url". If the rename is applied to a working copy and commited afterwards, the svnlook on the server does not show adding the mergeinfo property.

I cannot imagine a case where copying the mergeinfo to the new folder is a wanted behaviour, even worse, without the user being able to notice anything about such an operation.

Maybe there's something wrong in our setup? Or is this the expected behaviour?

The server currently uses httpd 2.2 + svn 1.8.13, the clients used for testing where svn 1.8.13 and svn 1.9.7.

Any insight is appreciated!

Greetings

Nico






Reply | Threaded
Open this post in threaded view
|

Re: svn rename adds mergeinfo property / renaming in working copy does not

Stefan Sperling-9
On Mon, Nov 06, 2017 at 06:10:37PM +0100, Nicolai Scheer wrote:
> I cannot imagine a case where copying the mergeinfo to the new folder is a
> wanted behaviour

The current behaviour was implemented on purpose.
It has been this way since Subversion 1.5.5.

See https://svn.haxx.se/dev/archive-2008-11/0432.shtml
and https://svn.haxx.se/dev/archive-2008-11/0297.shtml
for details.
Reply | Threaded
Open this post in threaded view
|

Re: svn rename adds mergeinfo property / renaming in working copy does not

Nicolai Scheer-3
Hi Stefan,


On 6 November 2017 at 19:06, Stefan Sperling <[hidden email]> wrote:
On Mon, Nov 06, 2017 at 06:10:37PM +0100, Nicolai Scheer wrote:
> I cannot imagine a case where copying the mergeinfo to the new folder is a
> wanted behaviour

The current behaviour was implemented on purpose.
It has been this way since Subversion 1.5.5.

See https://svn.haxx.se/dev/archive-2008-11/0432.shtml
and https://svn.haxx.se/dev/archive-2008-11/0297.shtml
for details.

Thanks for the pointers.

If I understand correctly, WC to WC copy/rename does not add mergeinfo in our case, because the source folder does not have any.
That seems to be change that has been commited as a result of the discussion you pointed out.

Still, I can't get from the archives why a URL to URL rename does add mergeinfo, although the folder to be renamed does not have any mergeinfo props itself.
But maybe I'm just not into the details why this can't be changed easily...

Greetings

Nico



 

Reply | Threaded
Open this post in threaded view
|

Re: svn rename adds mergeinfo property / renaming in working copy does not

Branko Čibej
On 07.11.2017 16:14, Nicolai Scheer wrote:
> Still, I can't get from the archives why a URL to URL rename does add
> mergeinfo, although the folder to be renamed does not have any
> mergeinfo props itself.
> But maybe I'm just not into the details why this can't be changed
> easily...

Copying a directory is the same as creating a branch. You need the
mergeinfo in order to know what to merge. The recorded mergeinfo
describes the source path and revision of the branch.

-- Brane