On Wed, Sep 17, 2008 at 12:25 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Sep 17, 2008 at 11:49 AM, Bert Huijben <bert_at_vmoo.com> wrote:
>
>>> ** How common this is depends on how "smart" we can make optional
>>> elision, but it seems likely that if subtree merges are done (as is
>>> common in the Subversion repository) then the subtree mergeinfo
>>> created is there for the long haul.
>>
>> Is it possible to easily detect if we could apply the same merge higher up in the working copy (e.g. on trunk/
>> instead of trunk/src/libraries/mylib) with (except for the merge-info) the same result?
>>
>> In that case it might be possible to just apply the merge higher up the tree, providing better merge info.
>
> I do not think this is possible, and probably not desirable. If you
> merge to a specific subtree, having merge alter a path above that tree
> would not be acceptable. It sounds like that is what you are saying.
>
> --
> Thanks
>
> Mark Phippard
Hi Bert,
What Mark is saying is true, *if* we are merging to
'trunk/src/libraries/mylib' we don't want to make changes outside of
the wc tree rooted at 'trunk/src/libraries/mylib'.
Though it's not clear that's what you meant...if instead you meant
that if we merge to 'trunk' and 'trunk/src/libraries/mylib' has its
own explicit mergeinfo can we set the mergeinfo on 'trunk' in such a
way as to have the same semantics mergeinfo-wise, well that won't work
either. Once a path has explicit mergeinfo it doesn't inherit
mergeinfo, so mergeinfo changes to 'trunk' have no effect on
'trunk/src/libraries/mylib' if the latter has it's own explicit
mergeinfo.
Or are we completely misunderstanding what you are getting at? If so
could you spell out a simple example?
Thanks,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-17 18:48:47 CEST