Branch? Fork? With a decent DVCS, they're the same.
Did you just clone your team's repository in order to work on it? Congratulations, you just forked. Even a checkout from a non-DVCS like svn is really a fork, if you think about it.
The best tooling passes this equivalence all the way to the user. git does an excellent job of it.
Then all you have left are semantics and namespacing.
That is very spot on. However, forking downsides are very real - more repositories to maintain, which results in harder to setup infrastructure (kicking off builds of 30 repositories is more work to setup than kicking off builds of branches in 1 repository). Installing webhooks or server-side hooks is also a bigger pain in a fork network.
> kicking off builds of 30 repositories is more work to setup than kicking off builds of branches in 1 repository
In git, just pull them all into one repository. It's trivial, provided that you are able to list the repositories and branch names (which is a namespacing problem).
"Welcome to Anonymous Corps Mega Enterprise (ACME),
Our publicist team is currently writing a letter to your employer on PasteBin while all our engineers are coordinating our sheeps to take down your employer's infrastructure until they decide to fire you.
Meanwhile, please enjoy this bucket of hate messages from our most recents intern.
When you look up at the clouds, do you see Adria Richards?
Is your every waking moment consumed by the possibility that some woman is being an oversensitive dickhead?
If not, then please stop dragging that stupid subject into other threads, some of us could use a vacation
This sounds like a subset of what Mercurial's ACL extension ( http://mercurial.selenic.com/wiki/AclExtension ) supports. ACL allows you to restrict by branch, but also by file path within the repository (so you can, say, reject any changeset that touches conf/security.ini on the default branch, or any changeset that touches authors/tom.jpg on any branch).
Sadly, ACL is not widely used or supported. It works on a machine where team members work as their own unix users, but it doesn't work under a shared login setup out of the box (although it's not hard to make that work). Bitbucket doesn't support it. I'm not aware of any installable repository managers that support it. This is a shame, because it's basically really good.
> The core team members work with the main repository in branches.
Actually, at my work, we all work in forks on BitBucket. Pull down from upstream before pushing to our fork, and sending a pull request to be reviewed then merged into upstream.
Works really well, especially with BitBucket's "Sync" button in the web UI for keeping your fork up-to-date with upstream.
I like that idea. I've never felt like github forking was a pain or something, but this may solve the problem of having a lot of forks going in several directions when upstream is not proactive enough in accepting pull requests : it will be way easier for one fork to rebase an other one.
One UX concern, though : it's not clear in the article if it's the case, but you should really let filter branches by owner/protected and third party ones, else it will be really hard to retrieve upstream version or features branches.
If you are self-hosting, both git and mercurial have that too. I am not sure if SAAS Subversion hosts allow to use AuthzSVNAccessFile - however Assembla Subversion has Protected Directories
Did you just clone your team's repository in order to work on it? Congratulations, you just forked. Even a checkout from a non-DVCS like svn is really a fork, if you think about it.
The best tooling passes this equivalence all the way to the user. git does an excellent job of it.
Then all you have left are semantics and namespacing.