> -----Original Message-----
> From: Paul Burba [mailto:ptburba_at_gmail.com]
> Sent: sexta-feira, 2 de Maio de 2008 15:14
> To: Leonardo Fernandes
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Redundant mergeinfo changes on subtrees with specialized
> mergeinfo
>
> 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?
Hi. Thanks for your reply!
Here I was talking about the following scenario: merging a changeset into wc, but having to commit files in wc/subtree without having their text modified. This is a no-op revision (for wc/subtree, that is), right? Maybe I'm abusing the term "no-op".
wc (merge-info modified as result of the merge)
|-- fileChanged (text modified as result of the merge)
|-- subtree (only merge-info modified as result of the merge)
>
> > 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?
Of course, the merge always works. I'm not discussing the correctness of the merge algorithm.
I'll give you my exact use case. We have a maintenance team which fixes a bug in a file. They commit the file, and propagate the fix to other branches. This is done by:
* switch the file (or some parent directory of the file) to a new branch
* merge the revision into the switched subtree
* commit the subtree
Why we do this, and not always merge in the root of the working copy? Because it's faster to switch, and faster to merge, and faster to switch to yet another branch.
Always merging from the trunk would at least spare the trunk from having explicit merge-infos. Why we don't always merge from the trunk? Because the bug might be easily reproducible in an older version, and from that point it will be easier to walk chronologically through all branches (v1, v2, v3, and only then trunk).
It will be easy to reach the described situation, with hundreds of files with explicit merge-info.
I hope my use-case is now clear.
Now, the problem that arises from this situation, bear with me. Merging something into such a branch would set merge-info in every subtree with explicit merge-info. This would result in lots of files pending for commit, without *relevant* changes.
Now consider that I want to double-check the merge results. I would have to iterate through all changed files, and diff with the base. My surprise will be that most of them are unchanged, with only merge-info changes, and I will be wasting my time filtering the really interesting ones.
Not to mention that, all files which received a merge from the maintenance team (in the use case I just described) will always be committed in every future merge. Think about what will happen to the log of such files.
And I dare to ask you the opposite question of yours. If I don't commit those subtrees, the merge stops working?
>
> > 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.
Please see below for an attempt of clarification.
>
> > 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
What I am describing is an alternative method to record the merges. I will try to enunciate it in a clear and formal fashion.
1. 'svn merge -rX:Y SOURCE TARGET' should *always* add 'SOURCE:X-Y' in the TARGET merge-info.
2. 'svn merge -rX:Y SOURCE TARGET' should add 'SOURCE/subtree:X-Y' to TARGET/subtree if and only if:
2.1. TARGET/subtree has explicit merge-info
2.2. and the merge operation actually changes some file in TARGET/subtree
3. 'svn merge -rX:Y SOURCE TARGET' should also elide any merge-infos in TARGET/subtree if possible
Of course, subtree could be N levels deep (N >= 1), and could be a file or folder.
Because of (1.) all merges done are recorded somewhere, even if they are no-operative merges.
Because of (2.) we would not need to commit files which weren't changed in a merge, just because the file had explicit merge-info. This is the main point of this discussion.
And finally because of (1.), (3.) is possible.
This suggestion solves the problems described in http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=136570.
I hope I was clearer this time.
Leonardo Fernandes
>
> > - 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 20:47:14 CEST