SVN - Multiple branches for project

I have one core site which has all the core functions.

I then need to create 4 sub projects which will use the same core site but will have different front ends.

From guides I think I could use branches but I couldn't work out if a bug is found in the core site would it be possible to commit changes to the core and then update the br开发者_JS百科anches ?

Thanks, Alex

Unlike other advices here I would recommend you to stick to the tool you are used to. Switching to git requires some solid background in SCM. It is more powerful, but also has a higher learning curve.

I would rather advice you to use an extra branch for the core that is pulled into the branches that use them means svn:externals.

For help have a look at the documentation here. This way you'll save yourself the tedious work of synchronizing the core for each branch. Even if you need one of your branch to stick to a specific revision of the core you can do it. The link does not even need to be in the same physical repository, what makes it a really flexible tool.

But make sure you use the 1.6 version for the client and server. I experienced some trouble with other versions as the format for the links appears to have been modified and extended.

I would rather suggest use a distributed version control system like git or mercurial. Although branching in SVN is O(1), merging isn't. In fact if the core is going to be the same you may as well make it a library and import it rather.

A branch should only be used if you are developing in one library. You would end up merging or pickaxeing changes for all repos - this is a nightmare!

I would suggest git too... svn has no submodules.

You can do something like this:

MainLibraryRepo: Your shared Code

Repo1: Site1

• submodule: MainLibraryRepo
• additional submodules ...

Repo2: Site2

• submodule: MainLibraryRepo
• additional submodules ...

Reasons for this setup:

• you can bind a Site to a defined version of your library (updates of your library can be tested before commiting the main Repo)
• the code that can be treated as a single unit should remain in it's own repo an have it's own history

Reasons for git:

• it's fast
• merging is easy and fast
• submodules is the solution you need here
• you can develop without server/client