Using BitBucket from a Corp. IT Perspective

[Eoin Campbell]

We're considering moving some of our code repo's from internal SVN Hosting -> BitBucket

We already use Jira & GreenHopper onDemand so integrating with BB DVCS (git to be specific) seems like a smart move, however there's a couple of things that irk me.

1. There doesn't seem to be a way to disable Forking a repo. Now this may seem trivial since ultimately, if the BitBucket users (i.e. our Dev Team) have an account to access the original repository, they could just pull that out onto a personal laptop at their whim. But still being able to simply click "Fork" and having an entire duplicate of the company source code in their personal BB Account seems "too easy". which leads me on to my second question...

2. Each developer/user would seem to be responsible for their own user account and then I as the repository/team owner invite them to access the team repository... I don't have central user control (and the ability to revoke their account) like I do with Jira & Greenhopper. Which brings me back to point 1, if a developer is about to leave, all he has to do is fork the codebase & hand in his notice.

I would then revoke his access to the team repository, but that doesn't appear to revoke the fork he took. Again there are probably ways around this, (if they sign up with a company email, revoke their email, redirect it, do a "Forgot Password" and "Password Change", revoke any account ssh keys,) but again this just seems to easy from a user pov and too hard from a corp. IT stand point.

Anyone have any guidance on these issues/concerns

[aMarcus]

Hi Eoin,

To answer your questions:

1. Forking is a core feature of Bitbucket and is, by design, not disableable. In the very common use cases for Git/Hg, your team members would be working from their own fork of your code and submitting Pull Requests to ask to put the code back in. Also, keep in mind that when a user 'clones' a repository locally, they also have a full copy of all of the source code and history associated with that project. That user could just as easily push the entire code base back up into a new account.
2. This is the way the Bitbucket service is designed. Most teams on Bitbucket consist of users who use their own account for accessing their personal projects as well as their company projects. Again, to your point about forking, there is nothing preventing that user from pushing the full source code up into a different repo on Bitbucket or any number of other code hosting sites. It should be noted, this is even the case with svn. Anything a user has access to, they can use the svnsync feature to take the full history of a repository and do what they wish with it, including putting a copy eslewhere.

To your other fork question. Again, you can't prevent that user from having a cloned copy manually placed on Bitbucket (or elsewhere), so there would be no great benefit to having a feature that would allow you to remove a fork from another user, and none is presently planned.

Bitbucket and hosted solutions in general may not be for everyone in every scenario. This is why we also offer behind the firewall versions of our software. For a behind the firewall DVCS solution, check out Stash. It offers greater felxability and user account control from within your own coorporate IT infrastructure.

I hope that addresses your questions directly. If you have any other questions, please raise them!

Cheers,

Marcus Bertrand

Bitbucket Support

[oxpayken]

Similar to https://answers.atlassian.com/questions/229768/fork-in-a-private-repo

Our approach is to mandate every developer to assign their fork ownership back to the team account.

Still, this does not stop user from copying the code in other ways but this problem is common for other version control tools.

Nevertheless, it is definitely a good feature request to have team able to create and control account for users.

[JH]

But there is a way to disable forks, right ? In

Repository
 > Administration
  > Repository details
   > Forking

has alternatives: allow forks, allow only private forks, no forks.

But as every git/hg clone is a "fork" too this doesn't help you that much if you're paranoid the developers having the copy of the codebase after their leave. But this is not only Bitbucket/git/hg issue but an issue with all VCS tools. At the same second you give a developer access to codebase, the developer can make a copy (unless you go to the extreme and codebase is only accessed from controlled secure physical locations and so on).

The best option with a hosted solution is to keep your repositories small and to grant access only on demand. Small repositories might be a positive side-effect of a good system design.