[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r32461 - trunk/notes

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Sun, 17 Aug 2008 09:11:40 -0400

gstein_at_tigris.org writes:
> --- trunk/notes/wc-ng-design Wed Aug 13 13:30:12 2008 (r32460)
> +++ trunk/notes/wc-ng-design Wed Aug 13 13:42:30 2008 (r32461)
> @@ -306,8 +319,12 @@ There are 3 known models for storing met
> groups of users:
> - in-subtree metadata storage (.svn subdir model, as in wc-1.0)
> + ###GJS: euh... aren't we axing this? who has *requested* this?
> - in-'tree root' metadata storage (working copy central)
> - detached metadata storage (user-central)

Yeah, I also had thought we were just going to stop supporting that
model, except in non-upgrade situations (i.e., okay, you can keep your
old-style wc, but then you don't get any of the shiny new features).

> +Basic Storage Mechanics
> +-----------------------
> +
> +All metadata will be stored into a single SQLite database. This
> +includes all of the "entry" fields *and* all of the properties
> +attached to the files/directories. SQLite transactions will be used
> +rather than the "loggy" mechanics of wc-1.0.

Some kind of logginess, or at least carefully ordered actions, will
still be needed, since we've got working files to deal with. But yeah,
I think the logginess will get a lot simpler with SQLite transactions.

> +Base text data will be stored in a multi-level directory structure,
> +keyed/named by the MD5 of the file. The database will record
> +appropriate mappings, content/compression types, and refcounts for the
> +base text files (for the shared case).

Sounds sane; we ought to be doing the same in the repository, really
(http://subversion.tigris.org/issues/show_bug.cgi?id=2286) :-).


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-17 15:12:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.