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

Re: The Four Elements of Righteousness

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-07-18 06:54:38 CEST

Greg Stein <gstein@lyra.org> writes:
> Big Brains solution #3:
> * add various consistency checks to what we store as a wcprop
> This is what Karl has done with ra_dav, but it really papers over the
> underlying problem that our WC is not properly transacted. Instead, this
> double checking is about *detecting* a WC in an inconsistent state. It
> doesn't *solve* the inconsistency problem.

Hee hee! I like the title you gave to this solution, but I agree, it
detects the inconsistency, rather than preventing it, and therefore is
not ideal.

> 1) the file's entry in ./svn/entries
> 2) the file's contents
> 3) the file's properties
> 4) the file's WC properties
> These four items need to be changed as a single unit. If you change any of
> them *WITHOUT* changing the others (or specifically knowing that it
> doesn't need to change), then you violate the internal integrity of the
> working copy.
> Thus, any solution needs to look at these four items as a unit, and
> transact them according.

Well said!

> Some Refinements
> * There is no need for a "master" log file.
> Our units of work occur entirely on a per-file or per-dir basis, except
> for altering directory info *after* its children have been updated. For
> example, we need to ensure all children are added/deleted before changing
> the revision associated with a directory.
> Thus, each time a file-log is completed, it can be run immediately.
> A dir-log cannot be run if any file-logs exist. Once the file logs are
> completed, then the dir-log may be run.
> The directory structure shown above, using the .svn/tmp/ subdir is not
> needed. We can simply move the logs directly up to .svn and omit the
> .svn/log file.

I think so, yes. We'll need to study this some more, obviously, but
this sounds about right to me.

> * Maybe eliminate the wcprops separation
> Initially, we decided to put the wcprops into their own files so that the
> props file would be just user-defined properties. This is somewhat
> artificial. Since we use the same API to set normal, entry, and WC props,
> we may want to just go ahead and keep them in the same file.
> This would reduce the number of inodes used by SVN, reduce the overall I/O
> because of few files to open/read/write, and reduce the number of items to
> transact (the Three Elements now :-)
> The WC's property functions would need to filter wcprops before returning
> them, but this seems very minor relative to the I/O to get the darned
> things in the first place (they could even be filtered at read time, based
> on whether the caller is interested or not).

Indeed, the WC would not even have to filter them out. We just put
them in the "svn:" namespace, under "svn:ra:dav:" or whatever. Since
Subversion itself, as a whole system, manages the "svn:" namespace, it
can certainly declare subspaces of that space to be reserved for the
ra layers, and a given ra layer can have its own subsubspace, and so
on. The client knows that anything beginning with "svn:ra:" is only
meaningful to some ra layer, and the ra layers sort out among
themselves who has what inside that :-).

So the wcprops just become regular "svn:" props, and our code gets
much simpler. Aaahhhhhhh...

> * Maybe keep a single log file and use IDs
> Not sure on this one. Maybe there is a simple two-pass scheme to read the
> log. Collect IDs, then reread to process the complete ones. This scheme
> would reduce the number of files needed, but I'm not sure of any other
> benefits or costs.

It would make log processing trickier, since right now we can just
stream through a log file in one pass, doing stuff as we go...

> I think that is about it for now. Mostly, this email can simply serve as an
> impetus for conversation to validate the basic "transact *all four* pieces
> of WC state" concept.


> p.s. no, this won't go into alpha; in fact, I would want to wait for the WC
> admin lock work to complete, and build off that

+1 again.

Thanks for writing this all out, Greg!


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 18 07:06:40 2002

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.