CODEWITHSUNDEEP
svnversion-control
Extrakun
Extrakun

Reputation: 19325

In SVN, how to maintain common code base which would be changed by 2 or more projects?

This question is in a sense related to "Best way to share common code", but the situation is slightly different in this case.

I am now coding an application, say A, for a project. It is unfinished and now a new project B, will be started and is basically a replicate of A with add-ons. As both projects are unfinished, it is likely that I will have fixes in A which I need to bring over to B; and perhaps enhancements in B which I would like to port to A too.

How should I use SVN for my situation?

Upvotes: 2

Views: 1178

Answers (3)

Macke
Macke

Reputation: 25710

It sounds like you want a new branch in your repo, where you either develop new stuff, or maintain the old. (You have to choose if you use the stadnard trunk/branches/tags layout). That is probably the easiest way to do this.

If you want to separate code, your options are:

  • Put all in the same repo, with top-level directories for each project (A, B, shared), or
  • Create two repos, A and B, use svn:externals to a third repo with the common code, where you have branches for A and B (if necessary) so you can easily merge betwen both.

Trying to keep separate versions in each repo is a recipe for disaster if that code changes independently in both projects. Merging between different repos are not supported at all, so don't go there. (Trust me. I've been there.)

Upvotes: 1

D'Arcy Rittich
D'Arcy Rittich

Reputation: 171559

If they are really that similar, I would just create a branch in Project A's repo for Project B, and then merge as needed.

Otherwise, extract the common code into its own new repo, and use svn:externals to reference it in each project.

Upvotes: 1

Avi
Avi

Reputation: 20152

Ideally, you should try not to have two copies of very similar projects in progress. That is a recipe for all kinds of trouble; trying to keep them in sync as you describe would require constantly merging back and forth, which is difficult and error prone.

Better, to build your project in such a way so that the shared parts can really be shared. Perhaps make it a library. Or perhaps, make them both one big project, with two different builds - one to build A, and one for B.

Upvotes: 1

Related Questions