RE: merge performance (was: Re: Distributed Subversion)
From: Todd C. Gleason <tgleason_at_impac.com>
Date: Thu, 11 Jun 2009 12:21:34 -0700
> -----Original Message-----
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
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
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
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.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
This is an archived mail posted to the Subversion Users mailing list.