Stefan Sperling <stsp_at_elego.de> writes:
> On Thu, Jun 25, 2009 at 05:07:01PM +0100, Philip Martin wrote:
>>
>> I don't know what you plan to do with the root path when you get it,
>> are you going to open it? If so I would suggest that rather than
>> create a path based interface you write some sort of open_with_root
>> interface that returns an access baton set (open_anchor is an example
>> of a path based interface being combined with an adm_open).
>
> I don't know if this is going to work in the context of
> the problem we're trying to solve here.
>
> See http://svn.collab.net/repos/svn/trunk/notes/commit-from-multiple-working-copies.txt
That's a hard problem to solve with the current code. If you are
planning to call your new function for every item in a commit then I
suspect it will be very unpopular, particularly with projects (like
tsvn?) that build up a big list of items to be committed rather then
doing a recursive commit, as it will be very slow.
How about a solution that doesn't use wc roots at all. The present
commit code uses one set of access batons that form a tree within a
single working copy. That tree goes far enough towards the root that
all the branches converge. That tree covers both the URL space, to
determine the anchor for the commit editor, and the WC space. I think
the solution is to separate the URL and WC spaces. Suppose that
instead of forming a single tree you created a tree for each commit
item, i.e. you have multiple sets of access batons. Then it's just
(ha!) a matter of carrying the multiple sets around and passing the
correct set with each item. Essentially you build a single tree of
URLs, to determine where to anchor the commit, but you build multiple
trees of access batons.
A solution like that is not a simple. However if tsvn ends up calling
your proposed new function a hundred times to commit a hundred items
in a directory, and each call has to read half a dozen levels of
metadata to get to a root, that has the potential to be a big
performance hit.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2365440
Received on 2009-06-25 21:08:40 CEST