SVN Branch in sync with trunk

Question

I am using SVN and my repository contains a trunk:

trunk
|
|_____A
|
|_____B
|
|_____C

I also have 2 branches with the same structure as the trunk:

branch
|
|_____DEV
       |
       |_____A
       |
       |_____B
       |
       |_____C
|
|_____PROD
       |
       |_____A
       |
       |_____B
       |
       |_____C

The trunk is used for ongoing development and the branches have the same structure as in the trunk but for different environments (i.e. DEV and PROD). I have a particular folder (folder 'A') common in both the trunk and the DEV branch which I would like to keep in synch i.e. any changes done in folder 'A' in the trunk are reflected automatically in the DEV branch in folder 'A'.

Which is the way to go? I have tried to build a post-commit script so that every change done in the trunk is committed to the branch automatically but till now I haven't succedded.

Answer 1

But why would you create the branch in this case? There are multiple problems which this approach.

1. Parallel development is not possible as in case as if team working on trunk commits something to solve some problem, it may break parallel development happening on branch1 or branch2. Consider the effort of stablizing branch1 or branch2 for what matters.

2. You will see many cases of conflict happening in trunk and branches.

Based on my experience working on multiple development project here is my recommendation. Hope this helps.

Keep a repository as parent and decide a merge plan on monthly basis (lets say). This will certainly have merge effort but stabilization effort would get decreased.

Another thing that can be done is to have a maven dependency in branch(s) which will use latest version released by parent repository. So copying whole repository while creating a branch can be avoided.

Answer 2

What is the complete difference between PROD and DEV environments? Is it a few files, one different directory? Is it a whole bunch of files?

Usually, something like this is handled as part of a build process. Then, during the build process, you can build a development or production release.

Some projects that consist of nothing but PHP or JavaScript files don't really need to be built. In that case, just zip up the files as an artifact you can deploy. Just make sure the files included are for the right environment. The advantage is once you have a build setup, you can do things like unit and smoke testing.

In Jenkins, you can then build two artifacts, one for DEV and one for PROD. If a particular build for DEV is good, you're pretty sure that the PROD artifact for that build is also good.

You can also build a single deployable artifact, and have the deployment process modify that deployment artifact for the right environment. Or use something like Zookeeper to keep the environment variables and settings in a Zookeeper instance, and just use a single artifact that can be deployed in any environment.

There's no reason to use two separate branches that must be kept in sync with each other.