On Thu, Jun 25, 2009 at 08:07:37PM +0100, Philip Martin wrote:
> 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.
Why does TSVN do this?
As you can see from HuiHuang's post, the function is going to
be called for each specified commit target. That is not necessarily
the number of items which will be committed (though it could be).
If TSVN runs into such problems they could also change their behaviour
and pass a comment parent dir of targets where possible.
And if it really turns out to be a big problem for them, we can
consider turning off the functionality before release.
There are multiple problems we're facing here.
One is the performance problem you described.
Another is that we're in-between wc-1 and WC-NG worlds, and so far
it's not clear how the problem will be solved in WC-NG. At least
none of the WC-NG gods have had time to come up with a solution and
explain it to us, and I haven't had the time to become a WC-NG god
myself yet.
Another is that Hui Huang is working on this as a summer of code
student, i.e. he's still learning how to develop code for Subversion.
At that stage, worrying too much about performance will impeed his
progress way too much. The resulting code is only half the goal here.
The other half is training a new developer, which works best if the
new developer has fun and sees functional results of his work relatively
quickly.
So I think that getting this to work somehow first, and then optimising
or even changing the approach entirely when WC-NG is ready for it
is a good approach. Not because I believe the result be perfect,
but because:
- Implementing the currently proposed solution will help us gain
insight into the problem.
- Implementing the currently proposed solution will help HuiHuang
getting to know the Subversion code base.
- The solution is not intended to be the final solution anyway because
we know WC-NG will do it differently (there won't be any access batons).
- We don't necessarily ever have to release the first solution, but
we have an option of doing so if it turns out to be acceptable.
> 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.
But you're still solving the problem in terms of wc-1. Maybe in a
more optimal fashion, but that does not matter, because wc-1 is
slated for replacement anyway. Any wc-1 solution is going to be
obsolete in a few weeks (hopefully) or months (more likely).
Stefan
Received on 2009-06-26 12:57:24 CEST