CODEWITHSUNDEEP
gitversion-controlbranchperforcedvcs
Jan
Jan

Reputation: 1975

Source control systems allowing partial branching

This was originally a question targeting git/bitbucket, but after finding our requirements cannot be supported, I'm searching for alternatives.

We have a main codebase that has some 'confidential' libraries. We need a way to create branch or fork for investigation purposes (for off-site workers) that will not contain chosen confidential files, but for all other files there still will be ability to push, pull, see entire history.

I've been able to achieve same in perforce/SourceDepot VCSs, however I want to see what are our other options.

Big plus would be an ability to migrate with history from bitbucket. Another big plus would be ability of some (even custom) http hosting for browsing codes/history that would have some ability to integrate with JIRA (as bitbucket/git does).

Here is an example of what I want to achieve:

Repo1(main):
 |-publicFolder
    |-file1
    |-file2
 |-privateFolder
    |-fileA
    |-fileB

Repo2(investigation):
 |-publicFolder
    |-file1
    |-file2

EDIT:

It appears that the scenario is achievable in mercurial by combining two things - convert extension plus the subrepos feature suggested by Lazy Badger

the convert part would need following filemap.txt:

include publicFolder

and following convert command:

hg convert --filemap filemap.txt path/to/local/Repo1 path/to/local/Repo2

next step is deleting the publicFolder from Repo1 and finally creating thin subrepo shell above both of those repos (to be able to treat them as a single repository if needed).

Upvotes: 1

Views: 78

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97355

  • Externals in SVN
  • Submodules in Git
  • Subrepos in Mercurial

are more or less notable and widely known iterations to the specified task (separation and aggregation) (you have to write, why it's wrong or there they are failed)

Upvotes: 2

Xavier T.
Xavier T.

Reputation: 42258

Perforce allows to have a workspace, i.e a working copy, configured with files coming from multiple depots.

You can then have different access right for the different depots [0].

See the multiple depot setup here : http://answers.perforce.com/articles/KB/2437

You would need a //public depot where everyone has access and a //restricted depot when a few people have access.

Then depending on the right, people would be able to create a workspace with either

//public/...
//restricted/...

or only

//public/...

Another big plus would be ability of some (even custom) http hosting for browsing codes/history that would have some ability to integrate with JIRA (as bitbucket/git does).

Perforce has some kind of web interface called P4Web. I have not used it myself and from what I have seen briefly it looks a bit outdated and quick Google told me it is no longer supported.

On the other hand, a dirty solution that will work with any SCM is to commit the binaries of your library into the public repository. This way you obfuscate a bit the source code. (That can still be disassembled to a certain extent).

[0] a Perforce depot is more or less equivalent to a repository in other SCM.

Upvotes: 1

Related Questions