

Dear Startup: Please make branching easy - palish

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 <i>not</i> make their tool do everything under the sun?  Here's a modest list of core concepts that seem useful:<p>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 <i>incrementally</i>, 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.  <p>Each individual's branch can sync to the main branch by pressing one button, and the system tries to auto-merge the results.  <i>Syncing is not branch merging</i>.  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.<p>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.<p>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.<p>Auto-merge is critical.  Every step should try to auto-merge, and only show a conflict when the same <i>part</i> of a file has been edited by multiple people, not just when the same file has been edited by multiple people.<p>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:<p>"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."<p>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.
======
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.

------
jsmcgd
Hear Linus Torvalds talk about Git:

<http://www.youtube.com/watch?v=4XpnKHJAok8>

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

~~~
sohail
Well said!

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

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

