On Wed, Feb 20, 2008 at 3:58 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> Some thoughts:
I do not want to sidetrack this discussion, but I have been question
since last fall when we were trying to solve WC to WC copy why it is
so important to create mergeinfo on a file when it is copied. You can
paint scenarios where it could be helpful, but in most cases I do not
think it is needed and I do not think it would be that bad in the
grand scheme of things if we just did not do this.
> The problem is that "/branch/bar" has mergeinfo "/trunk/foo:10-20".
> If the file's name were still "foo", that would be fine (the mergeinfo
> would be redundant and probably even elided out). But as the file's
> name is "bar", the reintegrate code can't certify that the branch has
> uniform mergeinfo, and therefore cannot proceed.
>
> Possible solution:
>
> When you encounter a file ("/branch/bar") whose mergeinfo disturbs the
> desired uniformity, run:
>
> svn_repos_node_location_segments(repos, "/branch/bar"
> <HIGHER_REV_OF_MERGE__PROBABLY_HEAD>,
> SVN_INVALID_REVNUM,
> SVN_INVALID_REVNUM,
> receiver_func, receiver_baton,
> authz_read_func, authz_read_baton,
> pool);
>
> The receiver_func should check the (svn_location_segment_t *)->path on
> each invocation. If any of invocations have a path P that
>
> a) corresponds to a path T in the merge target, and
> b) T matches the path given in the problematic mergeinfo, and
> c) P has no mergeinfo /or/ has mergeinfo that would be compatible
> with the uniform mergeinfo requirement
>
> then we can proceed with the reintegration. (Remember, P is really a
> rev/path pair, since it comes from an 'svn_location_segment_t'.)
>
> Also, if P is completely new on the branch (that is, it never traces
> back to any file that corresponds to a T on trunk), then we should
> just ignore its mergeinfo when determining uniformity.
If these things can be done it sounds like an improvement.
> Now, these strategies will not lead to pure, unadulterated goodness.
> Incoming merged changes still won't actually *follow* renames, so any
> changes to /branch/bar will just 'skip' when reintegrated into /trunk.
> It might be worth holding on to all the rename-tracebacks and printing
> out (and/or storing) their results in some useful way on the client
> side at the end of the merge, just so the user has somewhere to look
> to figure out any manual cleanup that has to be done.
I'd be careful about expanding the scope of this problem. The tree
conflicts work has the opportunity to improve these problems. We know
they are not easy to solve, I do not think now is the time to worry
about this aspect of the problem.
> (Actually, the change swill 'skip' only if there's no /trunk/bar;
> they'll try to merge and likely get rejected if there *is* a
> /trunk/bar, but that's not so much different from a 'skip' anyway.)
>
> Thoughts?
>
> I realize there are surely more edge cases here, but renames are the
> big one.
These sounds like good solutions if they can be implemented. In the
worst case, the user should still be able to use a 2-URL merge to
merge the changes to the WC. I do not know what happens in that
scenario, but it would be nice of the WC eliding code kicked in and
cleaned up the mergeinfo so that the problem does not continue on
forever.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-20 22:39:14 CET