HN Explorer

Dear Startup: Please make branching easy

9 points by palish ↗ HN
Won't someone please form a startup to tackle this problem? Branching sucks. It's one of those things that every smallish-to-large company has to deal with, and it's very non-trivial. Sure, there are a lot of complex issues, but won't someone please take a "Worse is Better" mentality and not make their tool do everything under the sun? Here's a modest list of core concepts that seem useful:

Each individual has their own branch. This individual can run a build of Product X and check in features and bug fixes. But most importantly, they can check in incrementally, instead of only when the feature is fully complete. For large projects, this would be very useful. Each changelist would still represent a feature, but the overall project might not be ready to deploy at that point.

Each individual's branch can sync to the main branch by pressing one button, and the system tries to auto-merge the results. Syncing is not branch merging. It doesn't create a changelist, for example. It should be the same process you'd go through when you're working in the main branch, only on your own branch.

Each individual can take checked-out work from the main branch and move it into another branch as a new changelist, without requiring a check-in.

Each individual can "save" their changelist at any time. When a changelist is saved, those files are copied and stored and the changelist is reverted. You can then fix a bug and check that in, then "restore" your saved changelist.

Auto-merge is critical. Every step should try to auto-merge, and only show a conflict when the same part of a file has been edited by multiple people, not just when the same file has been edited by multiple people.

Here's a quote from the CEO where I work. This was during an email conversation about branching, specifically that when you sync to the main branch it's actually a merge that creates a changelist:

"One of the key issues is the information you get from the changelist. It's not that we don't want to see checkins, it's that the checkins that result from [merging branches] don't convey information. Or if they do, it's not obvious and right up front like it is now. I puruse the change list every day to see what's going on. It's critical to my global view of what's going on."

So there you go. Make him happy and he'll give you money. We use Perforce, and it would be really great to have a layer on top of it to manage problems associated with branching.

13 comments

[ 4.2 ms ] story [ 42.5 ms ] thread
mattculbreth
Give Mercurial a try. We use it now and have had great results. We've each got a few repositories floating around and it becomes very easy to isolate certain features/bugs/fixes into their own little worlds.
vikram
I second that. Very good for deployment too.
intellectronica
Dude, have you tried bzr already? It's exactly what you need.

http://bazaar-vcs.org/

neilc
... or Mercurial, Monotone, Darcs, or Git, all of which make branching either fairly easy or utterly trivial.
dfranke
Has anyone here worked extensively with both darcs and bzr? I use darcs and love it. I hear some people rave about how much better bzr is. I've used it very briefly and didn't see what the big advantage was, but maybe I'm missing something.
bct
I switched from bzr to darcs for two reasons; `bzr pull` over HTTP is incredibly slow and darcs lets you cherry pick individual changes to record. Oh, and darcs bugs out sometimes and refuses to let me apply certain patches.

As far as I can tell, they're identical otherwise.

bootload
"... Dude, have you tried bzr already? It's exactly what you need. ..."

I'm pretty sure they could but look at the first few lines & read them again ...

"... Won't someone please form a startup to tackle this problem? Branching sucks. ..."

This is exactly an example of taking something that sucks and making it easier for users in this case developers to use. Take those "irksome" annoying processes and make something that does the job better: Read the bit on "What Customers Want". It "could" fit this description ~ http://www.paulgraham.com/start.html

sohail
"One of the key issues is the information you get from the changelist. It's not that we don't want to see checkins, it's that the checkins that result from [merging branches] don't convey information. Or if they do, it's not obvious and right up front like it is now. I puruse the change list every day to see what's going on. It's critical to my global view of what's going on."

"Like it is now" <-- What does that mean?

palish
For the most part, we all work in the mainline. Each changelist description is representative of the changelist.. That is, there aren't any "Work in Progress" titles. So our manager can read the changelist titles to see where the project is headed.

If we move everyone to their own branch, to simply sync to mainline we have to merge the mainline branch into our own. In Perforce, that means it creates a changelist that's checked in. Annoying when you're reading the unfiltered changelist titles, but there's something even more annoying: All your work has to be checked in before you merge from the mainline (otherwise you get horrible merging problems).

sohail
Whats wrong with having things checked in? If you are a real development shop, checking in is your lifeline.
jojoleflaire
You describe a social, not technical problem. There is already a solution today -- it's called your manager.

This is why the tools market is the domain of a few niche companies and IMO a waste of time for startups. Pain points at the level at which you could conceivably write code are all unique to the organization. It's a consultant's game -- A branching layer like you describe will be written in PowerPoint, not emacs. Do it and get yourself a promotion.