From: Mikhael Goikhman <[EMAIL PROTECTED]> > A good convention for naming commits seems to be: > > <user-name>/<checksum> > > where the `<user-name>' is nearly anything a client cares to pick and > `<checksum>' is a contents-summary of the resulting revision. This > both generalizes the requirements on and simplifies the implementation > of the revision-builder part of the system. > > Arch 1.x is bogus by too narrowly constraining `<user-name>' and > omitting `<checksum>' altogether -- but that's easily remedied.
And how exactly adding a completely random suffix to the namespace makes it non-bogus and maybe more intuitive? Sorry if I was unclear. I think the `<user-name>' should be pretty free-form (unlike Arch 1.x) and the `<checksum>' part is so that if two users happen to choose the same `<user-name>', at least a "fully qualified" version of that commit name (one that includes the checksum) will presumably disambiguate. > Of course, by one mechanism or another, clients must be able to > compute a list of the names of the ancestors of a given commit from > the commit itself. This returns to the familiar question of whether > and how to support some sort of archive-side ancestry-list caching. Yes, having to figure out the tree commit history, the latest archive revision, merged in revisions, and find unmerged partners, all make this <checksum> stuff look totally inconvenient and unpleasant to work with. I still think the current Arch namespace is close to the optimal. I agree but that is a mostly separate question from what namespace the tools should support. [Heh, Tom even uses the git terminology now, "commit" instead of "revision/changeset".] That's correct. -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/
