You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@red-bean.com> on 2008/08/17 13:15:17 UTC
Re: svn commit: r32468 - trunk/notes
gstein@tigris.org writes:
> --- trunk/notes/wc-ng-design Thu Aug 14 02:44:52 2008 (r32467)
> +++ trunk/notes/wc-ng-design Thu Aug 14 03:25:35 2008 (r32468)
> @@ -622,12 +622,129 @@ includes all of the "entry" fields *and*
> attached to the files/directories. SQLite transactions will be used
> rather than the "loggy" mechanics of wc-1.0.
>
> +###GJS: note that atomicity across the sqlite database and the content
> + of the ACTUAL tree is freakin' difficult. idea to test: metadata
> + says "not sure of ACTUAL", and when ops complete successfully, then
> + we clear the flag. during any future operation, if the flag is
> + present, then we approach the ACTUAL with extreme prejudice. also
> + note that we can batch clearing of the flags as an optimistic
> + efficiency approach (since if we batch 100 and the last fails, then
> + the other 99 will be slower until the wc-ng determines the ACTUAL
> + is in fine shape and clears the flag for future operations).
Heh -- I hadn't seen the above when I wrote
> 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.
just now. I'll read all your commits before commenting further. (Or
else just read the doc from the top.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r32468 - trunk/notes
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Aug 17, 2008 at 6:15 AM, Karl Fogel <kf...@red-bean.com> wrote:
> gstein@tigris.org writes:
>> --- trunk/notes/wc-ng-design Thu Aug 14 02:44:52 2008 (r32467)
>> +++ trunk/notes/wc-ng-design Thu Aug 14 03:25:35 2008 (r32468)
>> @@ -622,12 +622,129 @@ includes all of the "entry" fields *and*
>> attached to the files/directories. SQLite transactions will be used
>> rather than the "loggy" mechanics of wc-1.0.
>>
>> +###GJS: note that atomicity across the sqlite database and the content
>> + of the ACTUAL tree is freakin' difficult. idea to test: metadata
>> + says "not sure of ACTUAL", and when ops complete successfully, then
>> + we clear the flag. during any future operation, if the flag is
>> + present, then we approach the ACTUAL with extreme prejudice. also
>> + note that we can batch clearing of the flags as an optimistic
>> + efficiency approach (since if we batch 100 and the last fails, then
>> + the other 99 will be slower until the wc-ng determines the ACTUAL
>> + is in fine shape and clears the flag for future operations).
>
> Heh -- I hadn't seen the above when I wrote
>
> > 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.
>
> just now. I'll read all your commits before commenting further. (Or
> else just read the doc from the top.)
No worries. Strengthening or calling out a point is fair!
I'm going to be taking a look at the various operations to see what
happens if text-base or ACTUAL files just up and disappear (never put
there due to sync, or cancellation, or if manually removed). I'm
hoping to find a proper sequence of db/file operations such that we
can always recover, and/or proceed without a problem. In these cases,
I'm also thinking about caching hints to optimize interaction with the
filesystem.
We'll see... I still have to figure out the API and operational model.
Took a stab on the airplane back from hawaii, but I don't like the
approach. Thought of another model, and will try that later this
afternoon to see what it looks like.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org