There was a recent question over on the Kiln Knowledge Exchange about why when you started to nest branch repositories deeply, the UI didn’t scale to support long repository names.
I had a wry smile on my face when I answered that question because this particular decision was the topic of a few hours worth of discussion over the course of Kiln’s development.
Mercurial allows for an essentially limitless number of branches to be created, and branches can have sub-branches, and those sub-branches can have sub-branches, and…you get the idea. You have *so* *much* *power* (I am hearing the old He-Man cartoon in my head). The question I have is, “what problem is this super-powerful feature really solving for you?”
In truth, I can find a few valid use cases for these deeply nested branches (like extremely large teams working on a complex set of sub-systems). But 95% of the time, using deeply nesting branches is the wrong thing to do because it creates a real problem:
With so many choices, how the heck do I know which branch is the “right one” for my code?
The moment I hesitate like this when I am trying to get work done, I start thinking about ways to “get around” the problem because, well, I don’t have time for my tools to make my job harder.
Knowing all of that, the team got together and decided that the goals that should drive this design choice would be:
- Find a way to let people experiment with a limited number of nested branches because they might be right for what they are trying to do (it was right for us a few times)
- Find a way to discourage deeply nested branches because they can create confusion for users other than the branch-happy admin
- Make the UI to look nice
- Don’t do a lot of extra work to satisfy a requirement that only affects a small number of people
It took us a while to realize that the last goal should be on the list. But why should we spend a lot of time doing something that should, and was only likely to, be used infrequently? In other words:
What’s the least we can do, and still satisfy our goals?
In the end, I think we came up with a good solution. We didn’t gimp a user’s ability to experiment, but the UI certainly doesn’t encourage people to use deeply nested repositories. And for the people that really need them, there are some workarounds (like using Greasemonkey).
The good news is that, based on the feedback we’ve gotten so far, it’s working pretty well. Most users aren’t getting sucked in by the lure of deeply nested repositories. And, we didn’t spend a bunch of time up front trying to get the UI to support it, which means we were able to spend our time on things that people were going to run into every day.