[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-06-21 08:09:18 CEST

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

> On Sat, Jun 21, 2003 at 12:26:04AM -0500, cmpilato@collab.net wrote:
> > And I'm gonna guess that what you saw was 'lock' files being written
> > under tags/*, yes?
> Exactly.
> > For reasons that I honestly don't understand, 'svn commit foo' does a
> > full recursive lock on foo's parent directory. I've noticed this
> > behavior for some time now, but haven't had the chance to investigate.
> If this is indeed the wrong behavior(at least i believed so), I'll
> have a look some time next week unless someone picks it up.

Oh, it's wrong behavior -- no question there. And now I have a patch
in progress which locks the parent dir *non-recursively*, and then
locks each of the targets below that recusively (or not, based on
whether or not the commit was given the --non-recursive (-N) flag).
This seems to work as planned, except that in revision 3594, loooooong
ago, Philip Martin added this code:

  Index: commit.c
  --- commit.c (revision 3593)
  +++ commit.c (revision 3594)
  @@ -755,6 +755,21 @@
     SVN_ERR (svn_wc_adm_open (&base_dir_access, NULL, base_dir, TRUE, TRUE,
  + /* One day we might support committing from multiple working copies, but
  + we don't yet. This check ensures that we don't silently commit a
  + subset of the targets */
  + for (i = 0; i < targets->nelts; ++i)
  + {
  + svn_wc_adm_access_t *adm_access;
  + const char *target;
  + SVN_ERR (svn_path_get_absolute (&target,
  + ((const char **)targets->elts)[i],
  + pool));
  + SVN_ERR_W (svn_wc_adm_probe_retrieve (&adm_access, base_dir_access,
  + target, pool),
  + "Are all the targets part of the same working copy?");
  + }

Using my new locking method, I don't get this kind of sanity check for
free any more. But then, I don't know what prompted him to make this
change, since it's perfectly okay for 'svn commit' to commit from
multiple working copies (by my design, in fact). The commit code is
driven off of URLs, not on-disk paths, so perhaps Philip can page back
through the annals of time and tell me what was bugging him when he
added this code?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 21 08:09:06 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.