On Sat, Mar 15, 2008 at 4:09 PM, <dionisos_at_tigris.org> wrote:
> Author: dionisos
> Date: Sat Mar 15 16:09:52 2008
> New Revision: 29932
>
> Log:
> * notes/wc-ng-design: Commit today's work.
> + - metadata access API
> + wc_macc vtable-based API implemented by these modules:
> + * tree spread ('inspired' by wc-1.0)
> + * tree root (storing all metadata in the tree root (think darcs))
> + * central depot (storing 'somewhere' locally, possibly $HOME)
> + * non-local (retrieving all text and prop-bases from the server,
> + except for a number of cached ones) ###EHU: maybe this is
> + orthogonal to the question where metadata is stored: in all
> + situations, you *could* choose not to keep local copies
[I'm still a little behind on my dev@ mail from a vacation. I would
still like to get some of my wc-ng ideas down as well! Most of what
you have is great though.]
Honestly, I would see "supporting a tree-spread style metadata store"
as an explicit *non-goal* of wc-ng.
Having modularized abstracted APIs is great! However, an API does not
just consist of "given this input, what should the output be?": it
also contains "and what performance characteristics should I expect
from the API?". If code that consumes our metadata access API can't
assume that certain operations can be done efficiently (without having
to do an enormous filesystem crawl), then we're not going to write
that code.
After all, the chorus of "we could implement feature X easily, if we
had metadata all in one place" comes up over and over again. Sure,
I'm fine with abstracting "metadata at wc root" vs "metadata in
$HOME". And the "non-local" issue is indeed orthogonal: we'd still
have a single place that *knows* it doesn't have the text-base for
some files.
But the "scatter files everywhere so that it's easy for users to
accidentally delete things, every single operation has to assume that
part of the metadata might have disappeared, and you can't do any big
queries without a huge crawl" design should be an explicit non-goal
for a wc-ng design.
Trying to accommodate a design that *every single* post-svn open
source version control system has decided was a CVS flaw is not
something I'd be excited about.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-31 21:51:40 CEST