Not related to your post, but please do not reply to an existing thread to start
a new one. See here why:
http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post
Regards,
Blair
Leonardo Fernandes 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).
>
> 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. 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 18:27:40 CEST