Bookmarks in core?

[Augie Fackler]

On Dec 6, 2010, at 7:44 AM, Jason Harris wrote:

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

Retrain yourself to use 'hg pull --update <tag>' instead of 'hg pull --rev <tag>'. It's going to almost the same speed except on super-slow links or super-huge repositories, and it doesn't have all that bad behavior.

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