[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn commit" performance

From: <cmpilato_at_collab.net>
Date: 2003-07-08 21:47:09 CEST

Chia-liang Kao <clkao@clkao.org> writes:

> Ok, now I'm looking at this.
> so what we need to do is lock the grandparent non-recursively and
> each target recursively, also checks if all target are from the same
> repository.

This is what my patch did. But, like you, I ran into issue with the
locking code not discriminating about all the various working copies
that were being associated together.

That said, I don't think the fault necessarily lies there. Subversion
will eventually have to allow operations on multiple working copies,
so we don't want to slam the door shut on that.

I think that the better solution here is to:

  - do the locking as you (and I) have already implemented, and

  - no longer do redundancy removal during the target condensation
    step -- instead simply detect that a target that's already been
    processed has, well, already been processed

This will cause the commit to fail today as it should, but then
automatically start working later when we turn on multi-repos
commits. It clears up the locking issue. And finally, it doesn't
cost much more in terms of target traversal.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 8 21:47:18 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.