On Fri, May 2, 2008 at 9:01 AM, Leonardo Fernandes
<leonardo.fernandes_at_outsystems.com> wrote:
> 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.
Hi Leonardo,
I'm unclear how you are using the term "no-op revisions" above.
Do you mean a merge to a target that is inoperative in the source and
hence results in only mergeinfo changes on the target and subtrees
with explicit mergeinfo (possibly not even that if it is a repeat
merge)? This is how we use the term.
Or do you mean a merge that is operative in the source but doesn't
touch certain subtrees with explicit mergeifno in the target, but
those subtrees still get updated mergeinfo?
> 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.
How common is this use case really? I know some folks do nothing but
cherry pick changes to individual files. And many people do all their
merges to the root of branches. To get the situation you describe
we'd have to do both: Lots of subtree merges to create the 100's of
subtrees with explicit mergeinfo. Then merge to the root of the
branch.
Ok, assuming a lot of people do need to do this (I assume you are one
of them) then why is merging to this type of branch "hell"? The merge
works no? I assume you don't like the fact that there are (mergeinfo)
property changes on some of those subtrees that aren't changed in the
merge source?
> 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.
Sorry, I don't understand what you mean here. In particular, can you
give a concrete example of what you mean by "it's ok for a no-op merge
to set merge-info...in case of merge-info elision"?
I'm not trying to be difficult, but you'll need to spell out the exact
rules you are proposing before I can comment much further.
> 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.
Assuming you are talking about proper supersets/subsets, then that
doesn't seem to make sense. All "operative changes merged" to a path
is typically a proper subset* of "all merges ever done to it". So
what you are proposing is 'B':
--------------------------------------
| |
| SET A |
| All merges ever done to a path |
| |
| ------------------------------- |
| | | |
| | SET B | |
| | Superset of all operative | |
| | merges and subset of | |
| | *all* merges??? | |
| | | |
| | ----------------------- | |
| | | | | |
| | | SET C | | |
| | | All operative | | |
| | | merges done | | |
| | | to a path | | |
| | | | | |
| | ----------------------- | |
| | | |
| ------------------------------- |
| |
--------------------------------------
(*Yes C can be an improper subset of A, but in practice this is not likely)
Again, I'm not trying to be a PITA, I just don't understand exactly
what you are proposing :-)
Paul
> - 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
>
Received on 2008-05-02 16:13:58 CEST