[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: Greg Stein <gstein_at_lyra.org>
Date: 2003-06-23 09:51:51 CEST

On Sat, Jun 21, 2003 at 12:10:05PM -0500, cmpilato@collab.net wrote:
> Philip Martin <philip@codematters.co.uk> writes:
> > 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.
>
> Ah. Well, I can tell you why *that* happens. Look no further than
> svn_path_condense_targets(), which is going to drop foo/bar/zig/zag as
> redundant in light of foo/bar and recursivity.
>
> Hm. So your solution did the job, but at the cost of desired
> functionality.
>
> I will think on these things.

Sounds like we have to stop the "parse path/url arguments without context"
stuff that's been going on. Seems like we run into a bug every now and then
where we've been trying to handle some arguments without truly knowing what
the heck they represent.

Assuming some level of agreement, then the next question is: how to get the
right amount of context into the path condensing? Before each path can be
condensed, it would almost seem there is a question: can I combine >these<
two paths together? Some kind of a callback would have to say "woah! no,
those are separate WCs"

Of course, if our committing code traversed mixed-repos WCs, then we could
go ahead and allow the pathes to be condensed without worry.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 09:47:27 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.