The story of how SVN copy defeated SVN merge

So, I will immediately describe our situation and then explain why I gave this article such a silly name :-)

Our team of 4 people works on one project (until I say what kind of project, I hope I will write about it later)

We had 3 SVN branches: Production (stable branch that serves user requests), Staging (intermediate branch), Trunk (development branch).


During the iteration (we work on scrum, Scrum), programmers commit to one development branch (Trunk), after which changes and fittings accumulated during the iteration are transferred to the Staging branch using the svn merge command, where our QAs test and verify them. Further, in order not to make another merge on production (from Staging to Stable), followed by a panic test on production after the merge. All I did was change the configs on our web server. After release: i.e. at the end of the iteration, Stable and Staging swapped places. Stable became invisible to users, and the former Staging became production, that is, users go to it. So we got rid of one extra merge ... But this seemed to us not enough :-) There is nothing more unpredictable than an engineering idea ... We decided to remove the second merge, or rather the remaining one.

$HTTP["host"] =~ "^.*somehost.com$" {
.................
server.document-root = "/path/to/the/stable/branch"
....................
}

$HTTP["host"] =~ "^.*somehost.com.staging$" {
.................
server.document-root = "/path/to/the/staging/branch"
....................
}




$HTTP["host"] =~ "^.*somehost.com$" {
.................
server.document-root = "/path/to/the/staging/branch"
....................
}

$HTTP["host"] =~ "^.*somehost.com.staging$" {
.................
server.document-root = "/path/to/the/stable/branch"
....................
}








So, the condition of the problem: we have a development branch, which always contains the latest changes and two branches, each of which in turn plays the role of production.

During the last merge from developing to staging, we ran into big problems due to the fact that we all use different operating systems (Arch linux, Mac OS, Windows Vista), different IDEs (Eclipse, Net Beans, Notepad ++, VIM: - ))) And even different settings inside the same editors (now I'm going to write a specification about the unified editors settings). In this regard, different symbol sequences were used everywhere to translate the carriage, some editors replace the tabs with spaces, etc.

In this regard, during the merge, we did not receive conflicts, SVN was still dead !!! Actually the same pieces of code. And I had to manually cut everything out to bring the sorts to the desired form.

But at some point our nerves could not stand it! And I just dropped the staging branch (svn delete staging), and then we just copied the current development branch (trunk) to the newly created one (using the svn copy trunk staging command). All that was left to do was fix the configs in the newly created branch, and that’s all.

Therefore, as such, there is no merge. At the end of each iteration, the intermediate branch (svn delete staging) is deleted
and a new one (svn copy trunk staging) is created. And the configs to it are committed.

The only thing that bothered me was that the size of the repository would grow rapidly. But ... as far as I remember, SVN uses the Bubble-up method in particular to create branches, so the newly created branch is just a reference to an existing base one. And changes are diffs from this base branch.

Therefore, regarding the size of the repository, I am quite calm.

Now I'm sitting here writing this article, and QA is testing our project on staging :-)))

It is interesting to hear your opinions on this approach.

Z.Y.

In fact, I was even more interested in opinions about the merge in Git

For example, from the words of Linus Torvalds: “I know several companies that use git internally without suspecting it, because they still keep their main repositories in Subversion, but many developers then import the code into git because git really performs well mergers. So you can take the branch tree from Subversion, import into git, let git do the merge, which would be the main headache in Subversion, commit the changes and actually export them back to Subversion, and no one else will know that you used git. A little sad, but I heard about many working in companies exactly in this scenario ..... "

Git Google Talk