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.
+1
> 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!
-K
---------------------------------------------------------------------
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