On 1/17/07, Ivan Zhakov <chemodax@gmail.com> wrote:
> > I've been thinking about an alternative to libsvn_wc. The semantics of
> > this alternative library would be slightly different, enough that it
> > would not be perfectly compatible with the existing libsvn_wc. This is
> > why I propose this as an alternative library that follows as much as
> > possible of the current svn_wc.h API, that would be selected/enabled
> > at runtime, using a dynlib mechanism similar to the one we have for ra
> > and fs backends. From here on, I'll refer to this alternative
> > implementation as libsvn_wc_sqlite.
> Yes, yes, yes! I had the same ideas some time ago. Count me as
> volunteer on this feature.
Thanks!
> > I have never really used WC severability, but I understand there are
> > use cases, and more importantly, users of this feature. This would be
> > a first API exclusive to libsvn_wc_sqlite, something like
> > svn_wc_sever(), which takes a subtree of a WC and makes into its own,
> > standalone WC by creating a .svn/wc.db there and entering the relevant
> > metadata from the parent database. I haven't worked out the exact
> > behavior yet from the user's POV, but it would therefore mean
> > something along the lines of `svn sever wc_subdir; mv wc_subdir
> > somewhere_else`, instead of the current `mv wc_subdir somewhere_else`.
> I don't think that this feature is so required for users. At least for
> the first time.
Maybe, but we have a large user base, some of which have likely come
to rely on severability, either in their workflow or in their plain
old habits. I would like to offer some mechanism to not break things
too much for them.
> > This behavior is off by default however. The default is to crawl the
> > subtree rooted at cwd to work out what was edited, and to sanity check
> > metadata as you go. An option passed to svn checkout makes all WC
> > files read-only, and relies solely on the metadata to operate on the
> > wc, unless a particular operation forces a crawl.
> Hmm. Why you need this feature? IMHO crawling tree data spends most
> time in reading entries and creating locks, not in reading file
> timestamps.
> I think that most users like ability to any edit without any commands.
My main motivation for this is seeing NFS perform in an enterprise
setting. Its performance is not stellar (far, far from it), and
crawling the working copy requires a lot of readdir and stat calls,
all of which go out to the network as RPC calls. I would like to have
some mechanism to avoid those, if the user chooses to.
However, for users who don't want to adopt this, the default checkout
behavior would be to crawl. You do lose some of what you gained by
using a central store, but you still get the speed improvements that
come from not spreading the metadata all over the wc.
> > Text-bases now. By default, they are stored in the metadata sqlite
> > database (or maybe in a separate text-base sqlite DB alongside the
> > regular metadata. Details.). I would however like to have a clear line
> > drawn in the internals of libsvn_wc_sqlite, where we could add other
> > behaviors in the future. Say, no text-bases and fail all operations
> > that require them for ultra lightweight working copies, or no
> > text-bases but retrieved via the ra api when needed (which opens the
> > way for webdav caching proxies to work their magic).
> Btw, Are you sure that sqllite is ready to store very big data inside?
> Like 100 mb field?
The SQLite faq recommends switching to another storage system at the
100GB mark. I think a 100GB working copy has other problems to attend
to before looking at making sqlite groan :-).
According to DannyB, the biggest problem of SQLite is concurrent
access, which is gracefully handled in our case, as touching a working
copy takes exclusive locks anyway. However, there will be a wc
somewhere whose text-bases SQLite can't handle properly. That is why I
want a clean cut API within libsvn_wc_sqlite where we can drop in
alternative mechanisms to handle text-base storage, or lack of
storage. My favorite idea is the caching webdav proxy that can blindly
dole out the resources as fast as the wire can carry them, but there
would surely be other plausible ways to manage the text-bases.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 12:33:56 2007