The story of how SVN copy won SVN merge

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

Our team of 4 people working on the same project (until I say that for the project, I hope I will write about it later)

We had 3 SVN branches: Production (stable branch, which serves user requests), Staging (intermediate branch), Trunk (developer branch).
')

During the iteration (we work on Scrum, Scrum ), programmers commit into one development branch (Trunk), after this change and the features accumulated during the iteration are transferred to the Staging branch using the svn merge command, where they are tested and tested by our QA . Further, in order not to make another merge on production (from Staging to Stable), followed by a panicky test on production after merge. All I did was change configs on our web server.

$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"
....................
}


After release:

$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"
....................
}


Those. at the end of the iteration, Stable and Staging swapped places. Stable became invisible to users, and the former Staging became production, that is, it was users who entered it.

So we got rid of one extra merge ... But this seemed to us a little :-) There is nothing more unpredictable than engineering thought ...

We decided to remove the second merge, or rather the remaining one.

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

During the last merge with the de-staging, we are faced with 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 uniform settings of editors). In this regard, different character sequences were used everywhere for translating the carriage, some editors replace tabs with spaces, etc.

In this regard, during the merdzh we did not get conflicts, SVN all smerdzhil !!! Actually identical pieces of code. And I had to manually check everything out to bring the sorts to the desired look.

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 branch (using the svn copy trunk staging command). All that remained to do was fix the configs in the newly created branch, and that was all.

Therefore, there is no merge as such. At the end of each iteration, an intermediate branch is deleted (svn delete staging)
And create a new (svn copy trunk staging). And configs to her.

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 the already existing base one. And the changes are diffs from this basic branch.

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

Right now I am writing this article, and QA is testing our project for staging :-)))

It is interesting to hear your opinions about this approach.

ZY

Actually I was even more interested in opinions about merge in git

For example, from the words of Linus Torvalds: “I know a few companies that use git inside, unaware of it, because they still keep their main repositories in Subversion, but many developers then import the code into git, because git really does merge So you can take a tree from Subversion, import into git, allow git to do a merge, which would be a major headache in Subversion, commit the changes and actually export them back to Subversion, and no one else even knows that you used git. It is a little sad, but I heard about many people working in companies exactly according to this scenario ..... ”

Git google talk