[PATCH 3 of 3] ui: Add option to set number of revision hash digits displayed
mpm at selenic.com
Mon Jul 27 10:49:51 CDT 2009
On Sun, 2009-07-26 at 15:04 -0700, Eric M. Hopper wrote:
> On Fri, 2009-07-24 at 14:33 -0500, Matt Mackall wrote:
> > On Fri, 2009-07-24 at 12:20 -0700, Eric M. Hopper wrote:
> > > On Fri, 2009-07-24 at 13:52 -0500, Matt Mackall wrote:
> > > > On Fri, 2009-07-24 at 11:29 -0700, Eric Hopper wrote:
> > > > > mercurial/cmdutil.py | 4 ++--
> > > > > mercurial/commands.py | 14 +++++++-------
> > > > > mercurial/dispatch.py | 2 ++
> > > > > mercurial/patch.py | 2 +-
> > > > > mercurial/ui.py | 29 +++++++++++++++++++++++++++++
> > > > > tests/test-debugcomplete.out | 2 ++
> > > > > tests/test-extension.out | 2 ++
> > > > > 7 files changed, 45 insertions(+), 10 deletions(-)
> > > >
> > > > Not really happy with this one. I've been careful to keep ui largely
> > > > unaware of Mercurial's implementation details. The biggest exception is
> > > > path handling, and I've been planning to pull that out too. If we start
> > > > putting helper functions in ui, it's going to burst a dam and ui is
> > > > going to grow dozens of random helpers and become very ad-hoc.
> > > >
> > > > Couldn't we just update a node._shortdigits?
> > >
> > > That could be done. The problem is that there are a few places in which
> > > node.short is used which aren't intended for display on the UI. So the
> > > node module would have to get a new function that was specifically
> > > designed to format node identifiers for ui output. That would be
> > > perfectly reasonable to do though.
> > I would do the reverse: change the non-ui users to a different name or
> > possibly back to hex. What are these users?
> I went through and did an inventory and took some notes. There is one
> place where its used that I consider wrong, and one another where I
> consider it quite distressing.
> Additionally, URLs make for an interesting case. Ideally you would like
> URL identifiers to live for the entire lifetime of a repository. But I
> can think of a use-case in which 12 hex digits is likely to prove to be
> too small. If, for example, you had some kind of distributed filesystem
> built on top of Mercurial that did automated commits you could easily
> end up with a repository with over a million commits in it, and at that
> point collisions between 12 digit hex ids come with the realm of
> possibility. This means that if you still want URLs that last forever
> you will have to plan ahead for such cases and go for longer URLs.
Mercurial is not a good generic filesystem replacement, because
filesystems are not concerned with collecting volume-wide atomic
snapshots with every change. The overhead for irrelevant manifest and
changeset operations is not good here.
> The case I consider very distressing is where short node identifiers are
> stuffed into environment variables given to external programs.
> Environment variable values used to pass important information are not a
> UI feature, they are an internal feature, and those cases should be
> using hex.
> Lastly, changectx and filectx implement __str__ as a wrapper around
> short. I find this worrisome because it then becomes very hard to tell
> where its used. I think that changectx and filectx should have an
> explicit routine for getting a node identifier and that the __str__
> function should return a value that's a little more ornate than a bare
> hex short node identifier to discourage people from using the result in
> certain ways.
Sorry, this is just too convenient.
http://selenic.com : development and support for Mercurial and Linux
More information about the Mercurial-devel