gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: Arch revision namespace


From: Tom Lord
Subject: [Gnu-arch-users] Re: Arch revision namespace
Date: Tue, 24 May 2005 21:06:55 -0700 (PDT)

   From: Mikhael Goikhman <address@hidden>
   > 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]