> > 
> > Whoops, this is a good point.  However, the conflict resolution mechanisms
> > themselves would use the chunk fetching code, so it need not really be a
> > problem.
> 
> The problem situation I was thinking of was this: Client1 is connected,
> and retrieves the middle chunk of a file.  A write is made to the middle
> chunk, but before it can be written back, Client1 goes disconnected.  we
> now have a pending write on the middle chunk of a file, but only the
> middle chunk is on Client1.  Client2 now bops up and proceeds to modify
> the file in some manner, and succeeds.  Client1 now reconnects.  A
> Client-Server conflict has arisen and must be resolved for the change to
> be reintegrated.  However, because only a small part of the entire file is
> available on Client1, the resolution process may now be more difficult.
> Consider, for example, the case where it is an MS Word file.  An
> application-specific resolver is required, but it doesn't have access to
> the two complete versions of the file, so it may not even have access to
> the old file header :(.  The whole-file-in-cache is a simplification for
> version control that I think really does make life easier.

Correct me if I'm wrong, but both AFS and coda keep data on the servers
(in the RVM data file??) which allow one to recover files from 24 hours
ago. My univerisity has AFS, and I have recoved files I accidentally
deleted a couple of times like this. I also recall reading in one of the
coda manuals that this is possible.

If this is the case, the reintegrating client could request the full
version of the original file to allow reintegration.

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy_at_microux.com     |    hozer_at_drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------