How to sync(merge) to svn repositories...development -> production.

Question

We have two repos, a development and a production one. It was build so that test things went into the development one and then were merged into production now sometimes people forget to merge and they become out of sync. What's the best way to find all the changes in the development repo that are not in the production one?

Answer 1

I wouldn't merge everything, but copy the development version to get a new branch. This new branch is the current production version and gets frozen. You can do bugfixes within it and merge certain feature between the branch and the development. After some time, the development (trunk) and production (branch) are quiet different and you copy again.

That means, the trunk is the master and everybody works into that. Every branch is a version of your software and should be stable and frozen. Beside that, you could copy branches to try things out and if you happy with the result merge it into the trunk.

I think the above is best practice and widely used. However, some agile method might be against this ;-)

Answer 2

Check out the production version to directory A. Check out the development version to directory B. Copy all the files from B on top of the files in A (being careful not to copy over the .svn subdirectories). Then do an svn status or svn diff to see what is changed.

I use Eclipse, where any file that's been changed shows up with a little plus sign, which makes it very easy to spot. (Or it would, if only I had better eyesight and/or a bigger monitor.)

When SVN is trying to figure out if a file is changed, it doesn't do keystroke tracking or anything like that. It just compares the current version of the file to the cached version in the .svn directory.

I've never done this on an entire product, but I've used this technique a few times when, for one reason or another, I had a file that was updated outside of my workspace. (I was about to explain the circumstances but I realized that that would be long and boring.)

As another poster said, why do you have two separate repositories in this situation? I don't see how that gains you anything, and it adds a lot of pain on tracking change history and doing merges and the like. You can create two directories within a repository for "production" and "development" and probably get all the advantages and none of the disadvantages.