RE: merge performance (was: Re: Distributed Subversion)

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Thursday, June 11, 2009 12:38 PM
> To: Gleason, Todd
> Cc: Nathan Nobbe; Les Mikesell; Marko Käning; users_at_subversion.tigris.org
> Subject: Re: merge performance (was: Re: Distributed Subversion)
>
> On Thu, Jun 11, 2009 at 10:27:49AM -0700, Gleason, Todd wrote:
> > I discovered this by accident the other day: Merged revisions X, Y,
> > Z, and got a lot of conflicts and tree conflicts, because X, Y, and Z
> > were dependent upon A, B, and C. Re-did it adding in part of A, and
> > all of B and C. The remaining conflicts now made more sense and were
> > easy to handle, and there were no tree conflicts (files added in A, B,
> > and C and modified in X, Y, and Z).
> >
> > If I couldn't have done my partial merge of A, then I would have
> > probably done an svn copy of the new files, and a 2-way diff of the
> > modified files in A. Then I would have done B, C, X, Y, and Z. It
> > would have taken a lot more time that way.
>
> That's a nice use case.

Thanks. I forgot to mention, but I expect a less experienced user would not even do an svn copy, but would give up on making proper use of svn and copy them from another WC and do an svn add. Of course then they would have a much harder time merging down the road. The point is that not having the partial merge capability can lead to more pitfalls.

Of course, even with partial merge support, in the scenario above, such a user might resort to the svn copy or alternative copy as soon as the merge failed, rather than looking for dependent revisions at all. When I got the original errors I scratched my head and then looked through the logs to identify A, B, and C. If my original merge had identified some dependent revisions it would have helped. Something like "Conflict/tree conflict; consider merging revisions A, B, C first." This is probably a pie-in-the-sky feature but it would be easier than combing through history to identify all dependent revisions, and save some users from shooting themselves in the foot.

> We could have 'svnadmin elide' which tries to elide all mergeinfo
> in the repository as much as possible. This has likely been suggested
> before, but I can't find an issue in the tracker.
> Have to look harder, or ask Paul.

For what it's worth, it would be nice to be able to run this as a regular user. Our admins have less interest in having an easy-to-use repository than we do and prefer to only be involved for necessary changes (which currently include authz file updates/Apache restarts).

> Paul is very thorough about adding regression tests for the things
> he fixes. The test script containing the merge regression tests
> is among those that take the longest time to complete to run.

Then you're probably doing as much as you need to, or close to it.

> Yes, we need to get better at memory usage. There are some nice
> memory usage fixes going into 1.6.3, but there is definitely
> more that we could do about it.

I always prefer inspection as the first line of defense, but profilers can be a great second. I don't know if you're using any profiler tools, but I had some measure of success with them using C++ and imagine they're compatible with pure C.

--Todd

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2361420

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-11 21:23:09 CEST