On Oct 5, 2008, at 12:00 PM- Oct 5, 2008, Daniel Shahaf wrote:
> Greg Stein wrote on Sun, 5 Oct 2008 at 11:27 -0700:
>> 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.
>>
>
> *When* we have to validate the pristine file (bolded because it's
> a separate discussion), we can either open the database or open or
> stat
> the file. The checkmode_t constants probably allow the flexibility
> needed here (and if not, we'll discover it when we using them).
>
> (In a side comment, it feels weird that they are named after "what
> caller wants to do" and documented in terms of "what the
> implementation
> really does".)
>
>>> ...
>>>>>> 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.
>>
>
> If .svn is absent, we can ignore the error and fall back to scanning
> the
> filesystem. If all it stores is the wc root location, we won't have
> lost
> anything.
scanning the filesystem is not an option for larger repositories, svn
update, status etc
already take 20 mins for some of my repositories, i'm really hoping
that we can resolve this
with wc-ng
i also have many tools that delete the .svn directories on a regular
basis, with
the result that i have to spend time fixing up user working copies on
a regular basis.
Please, please lets move the .svn dir's out of the working copy
directories. Its just too
fragile to leave it there..
>
>
>> The .svn subdirectories also play hell with various "find"-based
>> commands. e.g. searching for something, counting lines or files, or
>> whatever.
>>
>
> Again, I'm not convinced that this really applies if it's just a
> pointer
> to the wc root. A 'grep' will only break for the wc root (and even
> then,
> there was the suggestion to store .svn in the wc root's parent), and
> counting lines will add you.. what? One line per directory?
---------------------------------------------------------------------
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 23:58:19 CEST