Re: "svn commit" performance

cmpilato@collab.net writes:

> + /* 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?

I added a the regression test commit_multiple_wc. It's basically

   'svn commit foo/bar foo/bar/zig/zag'

where foo/bar/zig/zag is a child of foo/bar, but comes from a
different working copy. I believe that in the past Subversion
silently dropped the second argument and only committed foo/bar.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org