Bookmarks in core?

Matt Mackall mpm at selenic.com
Mon Dec 6 10:38:14 CST 2010


On Mon, 2010-12-06 at 12:44 +0100, Didly Bom wrote:

> 
> Hi Matt,

[oh no, a gigantic email]

> The first thing that I noticed is that when you discuss the "Basic
> desirable tag properties" you set as a requirement that tags must be
> "In history". I think that here you are in fact mixing two different
> requirements, one of which is certainly essential while the other one
> is not. In particular, I think that tags must “_have_ history".

Correct.

> In section five you "Explore the alternate solution space". In there
> you have the section "What if we had separate revlogs for tags that
> weren't part of normal history?" where you say that:
> 
> "This would also be significantly more baroque and confusing from the
> user perspective ("There's a whole separate normally-invisible history
> of tags?")."
> 
> I think that this statement is not backed up by facts and in fact the
> opposite may be true! Where you _imagine_ a question such as "There's
> a whole separate normally-invisible history of tags?" I _get_ (on a
> day to day basis!) questions such as "Why does creating a tag create a
> new commit??", "Why does the "tag commit" appear as a child of the
> current revision?" and so on! So I believe that at most the fact that
> tags are "in history" is a User Interface decision.

Correct, I could have chosen five years ago to have a separate history.
I think this would have been a terrible choice, because most Mercurial
users would then never understand tags -at all- and their problems with
them would be even more mysterious.

Consider pull -r: most users can figure out why that doesn't work, even
if they can't figure out what they were supposed to do. But in a
parallel history approach, pull -r would still -serve the same purpose-
and thus work the same way. And only expert users who knew about the
secret tag history would be able to figure it out.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list