Derek Price wrote:
/:2 a/:2 b/:2 c/:4 /A:1
/B:1
/C:1
$ cd /a/b/c
$ rm C
$ echo new content >C
renders:
/:2 a/:2 b/:2 c/:6 /A:1
/B:1
/C:1
Incidentally, I think my solution may be slightly more efficient, even
in the case where add/delete/rename journaling is already happening.
Consider the above case. When the client requests /a/b/c/A:2/2/2/4/1
and /a/b/c/C:2/2/2/4/1 from the server, the server would need to either
process its journal for transactions 5 & 6 to see that file C was going
to change before it sent something like this across the wire:
/a/b/c:2/2/2/6 JOURNALENTRIES
/a/b/c/A:2/2/2/6/1 UPTODATE
/a/b/c/C:2/2/2/6/1 FILECONTENT
or just send the directory update (first line), wait for the client to
process the journal and rerequest the files (adding an extra network
turn-around), then send something like the second two lines above.
Using the global transaction ID as version numbers would enable the
server to see instantly that the client needed new content for file C
and skip updating the directory:
/:7 a/:7 b/:7 c/:7 /A:5
/B:6
/C:7
$ cd /a/b/c
$ rm C
$ echo new content >C
renders:
/:9 a/:9 b/:9 c/:9 /A:5
/B:6
/C:9
Allowing a client request for /a/b/c/A:5 and /a/b/c/C:7 and an instant
response from the server, generated by ignoring directories and simply
looking at the version #'s on the files themselves, like:
/a/b/c/A:5 UPTODATE
/a/b/c/C:9 FILECONTENT
Derek
--
Derek R. Price
Solutions Architect
Ximbiot, LLC <http://ximbiot.com>
Get CVS and Subversion Support from Ximbiot!
v: +1 248.835.1260
f: +1 248.246.1176
