Bookmarks in core?

[Jason Harris]

On Dec 6, 2010, at 1:32 PM, Adrian Buehlmann wrote:

> 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.

I liked Didly's write up of this. I agree that tags somehow should be different... I am well used to the way tags currently work. However, as has been noted many times, tags in different branches have conflicts during merges, and pulling to a tag doesn't include the tag, and the other problems etc. Thus, it's unequivocal that users are complaining and having issues with this feature.

> "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.

No!!  Once you use the words, the solution is "to educate users" because they are
surprised with current behavior, you *automatically* know you failed in the goal
of  making a nice UI. Mercurial is a nice UI in almost all other aspects, so
this, as people are noting time and again, is somehow a rough patch. Maybe its
intrinsic, but I don't know.

We all are writing Mercurial so users can use it. Right? Surely this is the end
goal!  If user after user after user, has a problem with the way something works
then the developers have to turn around and say. "Hmmm this is non-intuituve to
our users. How can we make this better?" Not that users need to unlearn their
"crappy old paradigms". (This is the perspective of developer centric behavior
and not user-centric behavior, and you need to have a user-centric behavior
thinking constantly about how users use things, finding out through experience
where they are falling down and making those bits smooth and easy...

Of course this user-centric view can clash with elegance inside your
implementation, break a paradigm that is clear and concise, and simple to you
etc... So maybe the feature is never changed... But never ever confuse deciding
not to implement / change the feature to a more user-centric perspective, with
the current state of affairs being the best way to do things as far as the user
is concerned if they only wised up and did things your way...

It disturbs me to hear the words "crappy old paradigms of users" and "uninformed
users" that you use above. If this is your true feelings then it makes me very
nervous about your design decisions re user interface design...  Instead you
should be fretting about "is there any other ways we can do this?",  "Are there
possible smooth ways to get around this problem that many users are coming
across?",  "How can we ameliorate the surprise the users are getting from this
feature?",  "What are the real alternatives?",  "What would change if we did
this the way users wanted?",  "Have I *really* investigated all possibilities".
etc. etc...

Then in the end the conclusion if you stick with the current way of doing
something that users find difficult is something like "It's unfortunate that
many users have problems with this. We investigated all the alternatives and
couldn't find anything that works better. We are aware this is a rough patch for
many users. Here are all the alternatives we considered... Did you have another
alternative that is distinct from these? Regrettably for now the only solution
is to educate the users..." (and be honest with yourselves /  ourselves that
this is a rough patch in your / our program...  And this problem should be
gnawing at your subconscious. All of us have such rough patches in our
programs... and its a balancing act of which ones we can iron out for what
effort, etc...)

Cheers,
  Jas