Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
"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 '11 at 22:35
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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