Ludovic> I'm not familiar with the `tla' code base but I think it'd Ludovic> be quite insightful if you could explain how according to you Ludovic> such a new storage model could be plugged in GNU Arch, Ludovic> technically.
There are deep and shallow parts. At the deep part, there's a need to add Arch's inventory and merging tools to the revc framework. At the shallow part, there's convenience command, front-end, and ancillary tool work to do. As an option, user's should be able to drive revc's manifest from Arch's inventory system. I personally go back and forth a bit on how much it is or isn't worth simultaneously tweaking inventory a bit (e.g., dropping some categories, adding a single-file mapping of file->id mappings, biting the bullet on one more change to how implicit (embedded in the file) taglines are found). The merge tools are all built out of mkpatch/dopatch which is layered on the inventory system. It would be worth floating these as independent tools and making them able to operate on trees within a revc archive (without having to check-out those trees). At a slightly higher level, the merge tools need to update revcs compact record of history. The higher level merge tools should use revcs history record rather than searching patch-logs. It's ok if they still provide for maintaining patch logs (desirable, as an option) but to do ancestor computations they should just use revc's records. At the shallow end: the revc code so far is ready-to-bind to your favorite scripting languages, either using a linked-in or a subprocess model. Presumably some users will want a subset of the CLI to be compatible, so, do that. There's lots of details within all of that but a finite number, none of which is very hard. -t _______________________________________________ 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/
