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

Re: CVS update: MODIFIED: libsvn_wc ...

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-08-31 16:19:42 CEST

Roman Neuhauser <neuhauser@mail.cz> writes:

> >The changes to svn_path_compare_paths are fairly trivial. I can
> >modify that this weekend to let it do:
> > contact.html <
> > orderform.html <
> > docs/biography.pdf <
> > docs/mailinglist.txt
> >
> >Before falling back to strncmp it is simply a matter of '/' counting.
> >The path with lesser directory seperators in it should be before the
> >other path. When the counts are the same, fall back to strncmp.
>
> Wouldn't just checking whether the dir's been locked already be easier
> and _cheaper_ than sorting the targets? I'm not really familiar with the
> SVN internals, so excuse this question: does one 'svn commit' after
> 'svn add'? You could be adding lots of files in one commit, sorting
> seems like an unnecessary burden. What have I missed?

The working copy commit-crawler needs to commit N targets spread out
randomly over a large tree. Because commits are atomic, it describes
the commit as *one* large edit to the tree; this means starting the
commit from a common "parent" directory and then traversing
directories in an intelligent order. The rule we want to follow is:
after we leave a directory (go "up"), we want to close the directory.
We don't want to have to randomly re-open it again. Thus, the crawler
is *already* sorting the targets. As Mike said, right now the targets
are being qsorted alphabetically, which guarantees that all children
in the same directory will be examined as a group.

You might want to read about "editors" in the spec. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006

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.