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

Re: Asynchronous delta editor and error handling

From: Tobias Ringström <tobias_at_ringstrom.mine.nu>
Date: 2003-10-25 16:24:01 CEST

Ben Collins-Sussman wrote:
> Tobias Ringström <tobias@ringstrom.mine.nu> writes:
>>A simpler solution is to define the following "rules":
>>1. If a delta editor operation returns an error, the editor is dead
>> (or wedged, or in an error state or whatever you want to call it).
>>2. When the delta editor is dead, further operations are ignored by
>> the receiver (and the driver must call abort_edit since every
>> other operation is ignored anyway).
> Perhaps we should just define an editor to allow asynchronous
> operations on a very small subset of functions.... in particular, just
> open/add_file(), apply_txdelta(), and close_file(). Nothing else. If
> we fail to transmit file1 (and don't realize it yet), that doesn't
> affect our ability to transmit file2.

Interesting idea, but I think it will still be too expensive to have a
synchronization point at every directory. If you have few files in
every directory it will hurt a lot.

Thinking... Since there already are strong ordering requirements on how
to use the delta editor, how about the following? If an error occurs
for a directory entry, all further operations on that directory entry
(or any childred) are ignored until either the corresponding close_dir
or close_file is called.

Consider the following tree


In this case a failed operation on file1 will not affect file2, but a
failed operation on dir1 will cause the operations on file3 and dir2 to
be ignored.

I think it will quite easy to keep track of this in ra_svn at least.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 25 16:24:46 2003

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.