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.
> 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 21:00:39 CEST