Stefan Sperling <stsp_at_elego.de> writes:
> Your solution would ultimately allow us to create just one single
> commit from multiple working copies.
> But we'd also have to modify the entire commit logic to deal with multiple
> access batons (as you said everything is centered around the idea of having
> locked a single working copy down from the root), and possibly even make
> changes to the svn_ra API so we can do the commit in multiple transactions
> instead of just a single one. Because, as far as I understand, support for
> splitting a single commit up into multiple transactions exists at the
> REPOS API level, but not at the RA API level.
I haven't really thought as far as that before. I assume that once
you opened multiple sets of access batons you would divide them up by
repository. For each repository you look at URLs to determine where
to root the commit editor, then do the commit in a single pass. It's
easy to drive an RA commit editor without access batons--svnmucc does
it. You only need the access batons once the editor drive has reached
the items that have changes. It's possible that most of the current
code doesn't really change beyond replacing the single access baton
set with some sort of list or map, and a bit of lookup to map commit
item back to the right set.
> And that's much more work than I anticipated for this Summer of Code project.
Maybe. I'm a little surprised that there is interest in doing commits
to multiple repositories with one command. The commits are
independent and will always be separate. Needing to run two commands
doesn't seem like a big deal. In my scheme above I would be quite
happy rejecting the commit if it spanned multiple repositories, it's
the multiple working copies that is interesting. I suppose I am not a
typical user!
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2365704
Received on 2009-06-26 16:14:26 CEST