On Sun, Oct 5, 2008 at 9:30 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>...
>> Well, checking the size *does* cost a stat(). If you look at the mode
>> to svn_wc__db_pristine_check(), you'll see different ways to check for
>> the presence of a pristine file. One of the modes won't even touch the
>> file -- it just relies on what is in SQLite. The "single" and "multi"
>> modes are good for "svn update" where you want to ask "hey. do I have
>> this file?" ... you can get a "no" answer really fast.
>
> Actually, I assumed that since we read the file (from disk) already, the
> cost of the stat() of the same file would be negligible.
Eh? No... we haven't necessarily read in the pristine file. We're
talking about the case where we're *considering* the pristine file. Is
it present? Is it usable? Should we fetch one during an "svn update"?
etc. In these cases, we might stat() the file to compare its size
against what is in the sqlite row, to verify the file is (still) there
and its size is proper.
>...
>> >> During a single svn command, you might hit some file in a subdirectory
>> >> as one of the arguments. The fact that it is "under" one of the
>> >> previously-discovered wcroots is NOT sufficient. You still have to
>> >> scan upwards to find a switched root, or an svn:external or somesuch.
>> >
>> > If you have .svn dirs: store the URL given to 'svn checkout' (or the key
>> > to the WORKING_COPY table).
>>
>> Assume we don't. There will only be one .svn directory, at the wcroot.
>
> I assumed the in-tree .svn dirs would just point to the wc root
> (basically 'ln -s ../../../../ .svn'). Are they really that bad?
> They would save all these upwards-scans-in-the-fs all the time.
Yes, they are. People have asked for years to get rid of them.
Primarily, it seems to come from the Mac dev community -- they have
some tools that assume they know everything in a given directory, and
when we throw something in there... they go wonky. Or they rebuild the
directory and leave our .svn behind. Crap like that.
The .svn subdirectories also play hell with various "find"-based
commands. e.g. searching for something, counting lines or files, or
whatever.
>...
>> > I don't see much difference, unless you also want to close them as soon
>> > as we don't need them (otherwise they'll all be opened soon after the
>> > start). And then, how do we know that a certain datastore isn't needed
>> > (at least for now)?
>>
>> No plans to close them...
>
> Then in the typical case we'll have all of them open shortly after we
> start. So I'd say, just open them all right away, and save us from the
> accounting.
Okee doke.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-05 20:27:49 CEST