Y'all are doing pretty well (Adrian, Miles, Martin). My $0.02... Yes, the fast-commit properties of git are winning. revc picks those up and fixes some deep flaws in git (weak integrity checking, awkward storage, inappropriate reliance on SHA1). From the arch perspective, this is a lot like the combination of two old ideas: revlibs that don't depend on unix hard links and commit-to-revlib instead of commit-to-archive.
Yes, name-independent file ids are critical to rename-handling smart merging. The arch inventory system is a *pretty good* framework for that and there seem to be no serious other contenders. Yes, sure, it might be worth adding the option to store the inventory in a single file, as has been long acknowledged. The convenience of taglines -- eliminating the intrusiveness of an explicit "rename" command -- is hard to beat, especially if (as in git/revc-style commits) the expense of examining taglines can be deferred to merge-time. No, trying to infer renames by glomming over history that doesn't include logical file ids is a lousy solution. The usual problems of expense and history lacunae apply. The git-family tools bug me because (among other things): ~ they are weak wrt SHA1 cracking ~ the blob format, with the header on each file, is wasteful and awkward ~ git's "big bag of every file in history" needlessly creates needs for expensive graph-tracing GC, complicates replication, complicates back-ups, etc. ~ git's weak binding of human-chosen names to revisions is silly: I don't want to have to use SHA1 strings in conversation or email but I do want the names I use to be definitive and secured within the revctl system ~ some variation on NIH syndrome is keeping them away from mkpatch/dopatch ~ git's logical history graph has the wrong topology ~ git's physical storage of history is needlessly inefficient and vulnerable to history lacunae The biggest annoyance is that what we've wound up with is, essentially, a global transactional P2P distributed filesystem -- over which people *should* be going apeshit and working out all kinds of interesting applications. But they aren't and they don't, which is sad. -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/
