Hi Jereon
>
> Hi,
>
> (my apologies for the spam if this is mail got send twice)
>
> I have observed that when a revision is merged with the --record-only
> option
>
> [...]
>
> Then subversion seems to still be downloading the revision delta,
> while I expected it to only update the svn:mergeinfo property.
>
I can't confirm or deny that. And will leave that with someone else to
answer.
>
> This becomes very apparent when trying to mark a large set of
> revisions, revisions that update some not so small binary files , as
> merged.
>
> While I expect this to be done quite fast and without any need for
> manual intervention I have observed the following:
>
> ·Tortoisesvn is downloading huge amounts of data 15MB so far in the
> following example:
> [...]
>
> ·The merging of the binaries conflict (no surprise there) at which
> point the merge is terminated with the message
> [...]
> Even though I checked the ‘Force merge’ and the status of the ‘merge
> non-interactive’ checkbox also has no impact on this.
>
The force-flag doesn't impact how text or property conflicts are treated
by the merge. See the TSVN docu:
/"The checkbox marked //Force the merge//is used to avoid a tree
conflict where an incoming delete affects a file that is either modified
locally or not versioned at all."/
The non-interactive flag only impacts that during the merge of a
revision, there will be no dialog popping up to let you choose how to
handle the conflict. You still have to do (aka: resolve) the conflict
after that conflicting merge though, before following revisions can be
merged.
>
> ·Lastly I noticed that the svn:mergeinfo property is not only updated
> for the relevant paths, as is done during a ‘normal’ merge. But
> instead it is updated for a lot of folders. Even the ones that are not
> changed in those revisions. Why is that? I find it surprising and
> weird that lots that unrelated folders have updated mergeinfo when I
> just mark a single revisions which changes a single as merged using
> this ‘—record-only’ option. Can someone explain why this is?
>
This is due to the internal workings in the record-only behavior of SVN.
In principle the design is that once a path (aka: directory) has a
mergeinfo entry, it specifies the full mergeinfo details.
That said, that if you have an existing mergeinfo entry in all of these
separate paths:
Foo
Foo/Bar
Foo/Bar/Test
then SVN will update all of these mergeinfo entries, if you are merging
a revision which contains the path Foo/Bar/Test, even though the changes
of that revision are only done in Test.
That's quite a bit simplified here. There's some great explanation on
that issue from Julian on the svn mailing list, though.
>
> I’m tempted to just manually update the svn:mergeinfo property on the
> root of my project excluding, which would easily achieve what I want
> to do.
>
> Is there any reason why I should not do such a thing? (I know, the svn
> documentation explicitly, strongly and multiple times warns against
> manually modifying the svn:mergeinfo property as the result is highly
> likely to be incorrent and/or incomplete)
>
One of the most common mistakes when manually changing the property is
the case described above (aka: missing the necessity to alter the
mergeinfos in parent paths). There are a couple of other problems (can't
list them atm) which you are quite likely to run into.
It might also be that in your case you have "unnecessary" mergeinfo
records in some paths. There's a tool in development which could help
with that, but it's usage is quite experimental and hasn't been released
yet (svn normalizer). If you wanna give it a try, MaxSVN's trunk builds
contain a 64-bit build of that tool:
http://www.luke1410.de/typo3/index.php?id=97
But I can't emphasize enough that it's quite an experimental
distribution/build.
--
Regards,
Stefan Hett
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3157558
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-01-29 11:17:09 CET