Bookmarks in core?

Adrian Buehlmann adrian at cadifra.com
Mon Dec 6 06:32:59 CST 2010


On 2010-12-06 12:44, Didly Bom wrote:
> 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. While your document addresses
> most of the key issues behind the design of mercurial tags it does not
> really address the UI issues that may be leading to the slight
> dissatisfaction that some users (me included) have with the way tags work.

"Why does creating a tag create a newcommit??":

Because it changes a project and it is an integral part of "what
happened" in the history of a project. There ain't no such thing as a
separate history for anything in a specific project.

Take mercurial itself as a good example: If Matt makes a new release he
tags a revision. That's an action done on the project as a whole. It's
an action like "I fixed bug X by modifying line Y of file Z like this".

And quite a number of projects use tags like that and people using it
understand it. That *is* a fact.

"Why does the "tag commit" appear as a child of the current revision?"

Tagging on anything else than the tip of the branch you want to tag
would by silly indeed in almost all cases. You might blame mercurial for
failing to protect you from every silly user action, but users who
understand how mercurial records history also understand how diverging
lines of history happen. And when forking history is probably a bad idea.

The solution to your "problems" is: educate the users. Not: try to tweak
core Mercurial until it starts to match what the uninformed users
currently happen to see as the best way.

Sometimes, you have to make users unhappy at first, because they have to
learn new paradigms or unlearn crappy old ones. As soon as they get over
it, they will thank you that you resisted the temptation to try to
implement their suboptimal, initial, simplistic view of the world.


More information about the Mercurial-devel mailing list