D4312: New bookflow extension for bookmark-based branching

idlsoft (Sandu Turcan) phabricator at mercurial-scm.org
Thu Oct 18 13:25:15 EDT 2018


idlsoft added a comment.


  First of all, thank you for reviewing the patch.
  
  We switched to mercurial a few months ago, mainly because of the narrow extension. Feature branches workflow was something everyone in the company understood and adhered to, so trying to adopt something else wouldn't be practical.
  Besides it was unclear what that something would be. Short lived branches were not recommended, evolve and topics aren't in core and take a while to wrap your mind around. Besides whatever we picked, it would need to be fully supported by Teamcity and IntelliJ. And Rhodecode.
  Writing a proprietary extension wasn't our first choice, not by a long shot. But at some point it was just the lesser evil.
  
  I see a lot of people focus on the DAG aspect of the repo, which for a core DVCS developer makes a lot of sense. You also mentioned anonymous heads, but this is not what we were trying to solve at all.
  In fact, as we realized at some point, tip and heads weren't very consequential for our workflow, but maintaining DAG references reliably was.
  A common problem we encountered was somebody starting their work, and before committing anything doing an `hg pull -u`. This would then move their bookmark to someone else's changes.
  To this day I can't quite see why it would make sense to move bookmarks on update. What was the original workflow that lead to that design?
  
  Basing a solution on bookmarks seemed like the least intrusive option. It would be client-side only, the only thing the server needs to do is protect certain bookmarks via the acl extension.
  Tools already support bookmarks, they just need to be more predictable.
  
  That's what the extension does. Really, if there was a config setting to not move bookmarks on update, I'm not sure we would have written anything at all (well, the fact that `hg bookmark NAME` can either create or move a bookmark is also not great).
  All the other functionality is trivial, to help guide the workflow and avoid confusion. We don't autocreate bookmarks, we just make sure you have one when you commit.
  
  While I understand the concern of endorsing too many branching models, I don't see this extension as introducing anything drastically new.
  It just addresses issues in the default bookmark behavior, which made them unsuitable for a pretty established workflow.
  Whether or not this is approved, I hope that can be revisited in core, perhaps made configurable.

REVISION DETAIL
  https://phab.mercurial-scm.org/D4312

To: idlsoft, #hg-reviewers, pulkit, marcink
Cc: smf, markand, marcink, durin42, jwatt, pulkit, mercurial-devel


More information about the Mercurial-devel mailing list