Walter Landry <[EMAIL PROTECTED]> wrote: > I think monotone stores history on a per-file basis. They work > exclusively with a local database, so they can quickly reconstruct > files. It is certainly fast [1], and it seems constant time.
I had a little chat with the monotone developers. I turns out that they store the latest revision and backwards diffs from there. So they have O(N) checkout, but N counts back from the head. This suggests that they just have a really, really fast patch applier. Part of this may be that they create each file independently, and only write to disk at the very end. Also, all of their patches are in one big db file, which can be easily cached into memory for the whole operation. I did some benchmarks on ArX, and it doesn't seem like running "patch" actually takes that long. It was maybe 30% of the time. It spends a lot of time figuring out that it doesn't have to do anything for a number of patches. This could certainly be improved with just a better patch format. So I think a new patch format is in the cards. I am thinking of making it a single file. At the beginning, there would an index, then all of the metadata changes (add, delete, rename, copy, is_patched, properties), followed by all of the xdelta patches (forward and backward). I think I can steal almost everything that I need from monotone in terms of diff3, pretty printing diffs, etc. That would get rid of the diff/diff3/patch dependency altogether. One nice thing about this is that it becomes fairly straightforward to translate this single file format into something you might email around. Note that this work on the patch format is independent of all of the other stuff. Cheers, Walter _______________________________________________ Arx-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/arx-users
