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-04-29 19:09:57 CEST