views:

94

answers:

4

While I know you can use a second repository for backup, or create a branch named 'privateBranchOfXcompletelyBrokenBackupOnly', I'm interested to hear about a version control system that supports remote private branches natively.

edit: forgot to tell that it should be remote private. Seems only mirror-pushing to a private repo mimicks this.

+2  A: 

Git does a great job of handling private branches natively. Each developer gets their own branch that they can do with as the please, then when they are ready to share their changes with the other developers, they just merge their changes back into the main branch.

It's certainly not perfect for everyone or for every project, but in many cases this approach has some great benefits.

bcwood
On the minus side, it is hard to get running under Windows, and the learning curve is somewhat steep. I have a hard time converting people to use it!
tucuxi
Yes, Git can be difficult to get working on Windows, but overall the tools have been getting much better lately. I still love the tools that SVN has, and actually use that more than Git. But in many cases, Git can be a great choice.
bcwood
+1  A: 

Any DVCS, such as Bazaar, Mercurial, Darcs, or Git, supports private branches.

John Millikin
+4  A: 

One of the great things about the new generation of DVCS (such as Git, which I use) is that an individual developer has great control over how they choose to work. Using Git, I can create my own private branches that mean specific things to me but not necessarily anybody else, and work with them locally without anybody else even needing to be aware of their existence. I can move changes between those branches, sort and organise commits, and only push my changes upstream when I'm ready to share them.

With a centralised system such as CVS or even Subversion, creating a branch is a world-visible, heavyweight operation that actually changes the shared repository. You have to be diligent in naming your branches (so individual developers don't collide) and manually clean things up when you're done.

Having said the above, Git also supports public branches easily, where I can create a branch, do some work, and push it upstream so that others can collaborate on that branch with me. Or, I can create a branch and a coworker can pull it from me directly without having to share it with everybody.

The site Why Git is Better Than X has more information about this feature. In fact, the first item is titled "Cheap Local Branching".

Greg Hewgill
A: 

As said any DVCS should do, but if you'd like them "local" as well - like you switch between branches in the same directory (which I found invaluable) you should most definitely prefer git here. Hg has some sort of support for this "local" branches, but once you've used them both you can clearly see the difference, and it doesn't make hg look any good. Workflow couldn't be simpler:
1. 'git clone git://some_server/some_repo'
2. 'git checkout -b your_branch_name'
3. 'do some work'
4. 'git checkout master' (or some other branch name, if you're not using master)
5. 'git rebase your_branch_name'
6. 'git push' or some other "git"-means of publishing your work.
And the best thing - everything happens in one directory, no more stuff like: checkout.000 checkout.001 checkout.002 :)

Dmitry