Bookmarks instead of named branches?

Issue #15 new
Matt Oswald
created an issue

Without knowing the internals of how Hg takes care of these things, would it be possible to have a flow configuration option that used local bookmarks rather than named branches?

Comments (11)

  1. Yujie Wu repo owner

    Right now, the implementation in hgflow is entirely based on named branches. So you cannot use bookmarks.

    But as far as I can see, it is possible to re-implement the branching model using bookmarks, providing the same functionalities. The question is how much advantage we can gain from using bookmarks vs named-branches.

    The major advantage of bookmarks is that you can reuse a name for a different branch after a previous branch with the same name has been closed. But a disadvantage is that you wouldn't be able to list the names of closed branches. I found this ability is quite useful in reminding me of the work that has been done (much easier to read than the commit log), example:

    hgflow> hg feature -c
    flow: No open <feature> branches
    flow: Closed <feature> branches:
    promote                           295:a0409dd9637a  2011-09-13 Tue 00:00 -04
    help                              291:22705aa44d7e  2011-09-11 Sun 22:47 -04
    0.9_docstring                     282:d0978e69df18  2011-09-08 Thu 21:46 -04
    refactor_remove_is_in             277:8e02a06120c3  2011-09-08 Thu 17:57 -04

    So I think the bottom line is that it's possible to enhance hgflow to use bookmarks,but I am unsure it is worth the effort.

  2. Matt Oswald reporter

    I would agree that branches are more powerful. However, there's one project that I'm working on where the rest of my team isn't as keen on Driessen's branching model as I am, and having a local-only option would let me perform my work in isolation without them knowing it's actually happening. (One developer is more familiar with Git and doesn't see the benefit of named branches at all, and he dislikes my flow branches.)

    I'll understand if you choose not to undergo the work, but I thought I'd get a discussion started. Maybe someone else has another reason to want to use bookmarks over branches?

  3. Yujie Wu repo owner

    I'm unsure how much a bookmark-based implementation can buy you in that case. Your coworkers can always see the merged branches. The only advantage of bookmark that I see is that bookmarks can be removed to make the branches anonymous.

    If the goal is to keep a branch completely invisible in the remote repo, you have to somehow delete the branch after merging. Say if we provide for the finish action an option to automatically do that (the effect is as if you got all the change in a single commit without branching-merging), do you think that would address the problem.

  4. Matt Oswald reporter

    Well, with a local bookmark option, no one remote knows that these branches are actually "named" for me. Honestly, I think it's kind of silly that a branch having a name bothers anyone.

    Hm. The option for the finish action would be interesting, but if I need to push the branch I'm working on (which I often do), the names will still be there until I finish the branch.

  5. Yujie Wu repo owner

    Well, if you push a branch to share with other developers, wouldn't it be better to name it? Actually to clearly refer to the branch, you will need some kind of name, which, if not a human-friendly one, will be a machine-friendly name -- the revision hash.

  6. Ron Winacott

    Also, if you push your unfinished flow branch to a shared repository, the branch is in the wild now. So how do you "remove the branch" if it is no longer local? You can't, it is in the wild. Unless??? you could rebase the start of the branch to the develop tip and remove the branch name? Just thinking out load.

  7. Anders Krein√łe

    Could performance in the long run be a reasoen to use bookmarks? The following is taken from the mercurial dokumentation about branching at :

    "Also, if you attempt to use a branch per bugfix, you may eventually run into performance issues. Mercurial is designed to work well with hundreds of branches. It still works quite well with ten thousand branches, but some commands might show noticeable overhead which you will only see after your workflow already stabilized."

    A relly active project can withoup problems get 10000 branches, if your use a branch per bugfix and feature.

    Actually this is the solo reason for me not using hgflow.

  8. Yujie Wu repo owner

    I think that's a good point. And I've done some testings, and below are the testing results and my thought on this issue.

    First, some timings of various hgflow commands on a repo with 10000 named branches and 80000 commits (my computer is a MacBook Pro with 2.5 GHz Intel Core i5 and 4 GB memory):

    • hg flow develop 10s, 12s, 15s
    • hg flow feature start new_feature1 17s
    • hg flow feature finish -c -m "Finished new_feature1" 14s
    • hg flow release finish 27s
    • hg flow feature list -c 3s

    This is certainly much slower than with smaller repos (where those commands are typically under 1s). But for big repos, the times are not outrageous IMO. I have been working on a big repo with git, it takes literally 1 min to complete a commit (on a very new desktop computer). Though ~20s can be annoying, it doesn't bother me so much to have to switch the implementation of hgflow to use bookmarks.

    That said, I would generally NOT encourage users to do feature/bugfix branching in a pedantic or extreme manner, e.g., create a new branch no matter how trivial the change is. My suggestion is the following:

    • If the task can be easily done with a single commit, there's no need to make the thing unnecessarily complicated by adding a new branch.
    • If you don't need to keep the revision history of the implementation of the task, you should finish the branch with hg flow <stream> finish --erase, which will delete the disposable branch after merging.

    I believe with a little bit care, users can avoid a lot of unnecessary branches when using the hgflow branching model.

    So I am still not compelled to make major changes to support bookmarks. Named branche has some advantages (as mentioned in the previous comments in this issue) that I don't want to lose. As for the potential performance overhead of named branches, it will at least take a while to be a realistic problem: Even for a very active repo (say 30 code-changing commits per day, and 4 commits per branch), it would take ~5+ years to reach 10000 branches. And that's perhaps the worst case; with some discipline in creating and keeping branches, it would take ~10 years or even longer. By then, I wish the Mercurial developers would have already addressed the performance issue or provide ways to altering the revision history such that the branch names could be deleted.

    Sorry if this is disappointing. But I am really lack of time/energy/motivation/whatever to make this as good as you would have wished.

  9. Brian

    I am also interested in using bookmarks as opposed to named branches -- I might even be interested in starting a branch or fork (or both) just to develop this feature.

    My primary reason for wanting bookmarks as opposed to named branches is for GIT interoperability. With hg-git, I can use GIT repositories so long as I use bookmarks as opposed to named branches. This is an excellent tool with its roots in git -- why not be compatible? One of the reasons I love Mercurial is that it is an excellent tool, and allows interoperation with GIT in a fairly transparent way. It would be nice to have hg flow working with that as well.

  10. Log in to comment