Hi.
I have read the thread you pointed to. Thank you.
But it still confuses me why a SCM software forces me to commit no-op revisions, just to get things right in the merge-tracking feature. Here's my point of view, which is of course as valid as yours, but very different.
When I merge a no-op changeset into the folder /my/folder, it doesn't surprise me the need to commit /my/folder to record the merge-tracking info. But it does surprise me the fact that I need to commit also /my/folder/my/subtree, just because it has explicit merge-info. I'm not telling it's unacceptable, but it's just confusing. And even more confusing because I cannot explain that behavior to anyone without drilling down into the Subversion implementation, merge-info properties, and subtrees with explicit merge-info.
Imagine a branch with hundreds of subtrees with explicit merge-info. Merging in it would be hell.
In my opinion, it's ok for a no-op merge to set merge-info in the *root* of the merge, or in case of merge-info elision. It's an alternative implementation, which you might consider.
1) Multiple Merges vs. Merge with Multiple Ranges Can Result in
Different Mergeinfo
This would not be true, unless for subtrees. Let's see:
svn merge -c11 SOURCE TARGET
svn merge -c12 SOURCE TARGET ---> no-op, mergeinfo set *only* in TARGET
svn merge -c13 SOURCE TARGET
The result now would be '/SOURCE:11,12,13'.
In my personal opinion, the result '/SOURCE:11,13' would not be incorrect either, but from what I can see that would cause merge-info elision to fail. That's an acceptable argument.
2) It Thwarts Elision
No it doesn't, because:
- Each tree node will have:
1. a superset of all operative changes merged into the node;
2. a subset of all merges ever done to it.
- A svn merge -rX:Y SOURCE will elide any subtree with merge-info contained in X:Y, even if it's a no-op merge. It would even possibly elide in more cases than the current implementation.
Thanks for reading, and I'm waiting your comments on this subject.
Leonardo Fernandes
-----Original Message-----
From: Paul Burba [mailto:ptburba_at_gmail.com]
Sent: terça-feira, 29 de Abril de 2008 18:10
To: Leonardo Fernandes; dev_at_subversion.tigris.org
Subject: Re: Redundant mergeinfo changes on subtrees with specialized mergeinfo
On Tue, Apr 29, 2008 at 6:42 AM, Leonardo Fernandes
<leonardo.fernandes_at_outsystems.com> wrote:
> Hi. I just want to discuss a use case which is occurring with us.
> Suppose we have a project structure such as follows:
>
> trunk
> |- moduleA
> |- moduleB
>
> We create a branch by copying trunk to branches/mybranch. Merges can be
> done for the top-level directory (from trunk to branches/mybranch), or
> just for one module (from trunk/moduleA to branches/mybranch/moduleA).
> Sometimes we may even perform a merge on a single file deep in some of
> the modules.
>
> After a few such merges, we have specialized mergeinfo in
> branches/mybranch/moduleA (and in other places as well).
Hi Leonardo,
A note on terminology: I know what you mean by "specialized"
mergeinfo, but we typically refer to this as "explicit" mergeinfo (as
opposed to inherited mergeinfo).
> Now suppose we commit a file in trunk/moduleB/file. Now we merge this
> commit into a branches/mybranch working copy. This not only changes the
> file moduleB/file, but also changes the mergeinfo in all subtrees with
> specialized mergeinfo (including moduleA).
>
> Now, as far as I can tell, those changes in moduleB and other unchanged
> files are redundant, since the revision being merged has no changes at
> all to those subtrees.
We in the development community struggled with the question of setting
explicit mergeinfo on a path for ranges that are inoperative in the
merge source for that range. An even simpler example than yours is
when we merge SOURCE -rX:Y to TARGET and TARGET has no subtrees with
explicit mergeinfo. It's easy to imagine many revisions Z, where X <
Z <= X that are inoperative in the source, heck, the entire range X:Y
might be inoperative!
But we still set mergeinfo describing -rX:Y. Partly this is for
simplicity, it keeps the mergeinfo ranges short and easily readable,
especially for feature branches. But it also means that multiple
individual merges that are semantically equivalent to a single merge*
produce the same mergeinfo. It also encourages mergeinfo elision.
See this thread for more:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=136570
Paul
* e.g. svn merge -c3, svn merge -c4, svn merge -c5 should produce the
same mergeinfo as svn merge -r2:5
> And why should I commit a file/directory
> resulting of a merge, when I am sure it wasn't changed?
> IMHO this confuses the user, makes it difficult spotting the real and
> relevant changes in the list of changed files, and pollutes the logs
> with irrelevant commits to those files.
>
> We are using svn 1.5.0-rc4 and TortoiseSVN as client, if that matters.
>
> Leonardo Fernandes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-02 15:01:27 CEST