2005/7/12, Aaron Bentley <[EMAIL PROTECTED]>:> > Contents storage should be an > abstraction: request contents for id foo, receive stream for id foo. > (Your IDs are SHA-1 sums in Arch and git. Other VCSes may use other > ids.) Only the storage implementation should have to worry about the > pysical representation of the contents. > > It should be possible to add additional storage formats based on weaves, > or tarred patches, or rot13 encoding at a later date.
Yes, clearly that's the right thing. I'd have absolutely no complaint if arch2 came with only the "unpacked" form at first, as long as it would be easy for somebody else to add another storage backend in a way that's more or less seamless for the user. If revc requires the unpacked form for its commands, then I suppose other types of backends could create them in the same way tla makes revlibs now, as a cache. [Gee I guess I should get off my duff and actually download revc and look at it...] -Miles -- Do not taunt Happy Fun Ball. _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
