4

I'm currently working on a project that has both an open-source "community edition" and a set of closed-source features for paying clients. One of the pain-points right now is figuring out how to handle keeping the shared source in sync between projects.

We use Mercurial for source control, and the open-source piece is pushed to both CodePlex and Kiln, while the closed-source piece is pushed only to Kiln. We're presently keeping them in separate repositories with project references into the open-source repository where applicable.

Is this really the best way to handle this kind of situation, or if there's something I'm missing (like using a subrepository within the closed-source repository to contain the open-source portion) that might be easier and cleaner to work with?

3 Answers 3

3

The real benefit of your subrepository idea is that it ties revision dependencies together between the two projects. In other words, if a new closed source feature depends on an open source version, when someone gets one they automatically get the other. If you back out to an earlier closed source revision in order to do a hotfix, you automatically get the open source revision you originally built it with. There are other ways, like configure or build scripts, to manage those kinds of dependencies, but they are more difficult to maintain.

1
  • "If you back out to an earlier closed source revision in order to do a hotfix, you automatically get the open source revision you originally built it with." -- This is exactly the behavior I'm looking for, but couldn't quite determine if subrepos did that.
    – Sean
    Aug 10, 2011 at 22:35
1

From what I can tell, you are essentially working on two "projects": one open source, the other closed source. I don't see there being a problem if these two "projects" are kept separated (i.e. kept in separate repositories).

How you manage both of these "projects" depends a lot on how they are individually designed and how well one can integrate with the other. For example, if one of the "projects" is a closed-source library, the other open source "project" can integrate and use this library without having access to the source. I have a feeling you are doing this already. You can manage this separation by having separate teams responsible for each "project" and coordinating between themselves when necessary.

0

An other option, that I use, is similar to the subrepository, but the other way round. Background: In my case the open source part is a server and the close source are some plugins that clients may want to pay for.

The closed source parts start in a plugins/ folder that is .gitignore-ed in the open source project. The folder itself is a private git repository.

When you ./config.sh the whole project, either it finds the extra files and then make will build the complete project or it doesn't and it will build the open source project without the plugins.

Not the answer you're looking for? Browse other questions tagged or ask your own question.