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

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Wednesday, June 10, 2009 11:28 AM
> To: Nathan Nobbe
> Cc: Les Mikesell; Marko Käning; users_at_subversion.tigris.org
> Subject: merge performance (was: Re: Distributed Subversion)
>
> If it is enough for most other systems to solve the simple problem
> of merging at units of entire revisions only, then maybe that is
> what Subversion should be doing, too. We could do away with subtree
> mergeinfo, just have mergeinfo at branch roots and declare rX merged
> into branch B as soon as someone merges _anything_ from rX into
> branch B. If you want to merge more from rX, well, then undo the
> previous merge of rX first, and then merge rX again. From conversations
> I've had with Paul (our merge-tracking guru), it would seem that this
> strategy would improve performance a lot. Would people like this?

I just made use of this capability (for my first time) two days ago, because I had committed more than I wanted to merge between branch/trunk at the moment. So I think it's useful, and something to be mentioned as a superior feature of Subversion. Obviously, when you merge a partial revision, you want to make extra sure your merge results are good before committing them, but without this feature, you would end up doing the same thing by hand, and have to clean it up later when you do the actual merge.

What I would really like is a way to prevent subtree mergeinfo from being endlessly maintained, and maybe to clean it up by migrating it towards the root.

We're using Subversion 1.6.2 client and 1.5.2 server at the moment, BTW.

For sake of discussion, assume we have a working copy directory structure like this:

Root\L1\L2\L3\L4 (in Windows)
(Root = trunk or something similar, not the actual root of the repo)

The directory names are just abstractions, of course. I may have several parallel L1's, L2's, etc.

Say I do a merge to L3 and commit L3. L3 now has mergeinfo. It all works quickly right now because L3 doesn't contain more than a few L4 directories, and I felt more comfortable merging to L3. All the merged changes in this case fit under L3, so the merge results are effectively the same whether I merge at L3 or at the Root. The only difference I know of is where the mergeinfo would get recorded.

As time marches on, lots of other L3-level directories get mergeinfo, as well as L2-level folders, etc., up to the Root itself. It's a mess and every time a merge is done to Root, ALL the mergeinfo properties get updated. Why? I don't know, especially when most of them seem completely unrelated to any given merge. I end up committing only the directories containing what I think is relevant mergeinfo. And then I just revert the other mergeinfo changes anyway. What a pain. I'm fighting Subversion.

What I would like is for the irrelevant mergeinfo not to get updated. Doing that alone might be sufficient. Then it might not matter whether I merge at L3 or at the Root, it might all still work okay.

It also seems like it would feel cleaner somehow if mergeinfo migrated up towards the Root. I'm not sure if this would work though since a user could checkout from L3 and therefore not have a Root in their WC. But if it were possible, it would consolidate a lot of mergeinfo. Certainly Subversion could be detecting whether a merge contained all the changes for particular revisions; it really seems to mostly be a question of whether your WC has the Root, and also whether your client/server combination can check mergeinfo that might be outside of its own contents.

Again, if Subversion just didn't always update every bit of mergeinfo in your entire WC, but only updated the mergeinfo for whatever got changed, it might solve the problem sufficiently that I don't really care where the mergeinfo is.

Maybe there are some complex technical reasons why Subversion behaves as it does right now, but if so, I don't understand them, and I don't think most users want to understand. We simply see an ever-growing number of files/folders getting modified properties as a result of a merge, and it confuses us so we struggle to commit a sane merge result.

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-11 18:07:30 CEST