Developer Deployment in SVN

Question

Our team is invited to upgrade CVS to SVN, and although it’s not exactly Mercurial or Git, what I was hoping for is at least a step in the right direction.

I know that a big hang for development teams - at least with SVN (or any other industry-specific SCM) - is the topic of branching and merging.

I read articles preaching that “branches of signs” (branches covering the development of a certain new function) are pure evil. And after reading them, I am inclined to agree. But then the question arises of when branching and when to combine ?

I was engaged in the idea that the developers are checking the chest / but each of them has their own (separate) branches of developers and introduce new code into these branches. Then, whenever the developer completes his work, we simply combine the code related to this work (located inside his "private" branch) with the trunk. That way, they are not holding anyone else, and if they are left behind, they will not stop the release.

It’s just interesting what thoughts were focused on developer-centric development. If this is a terrible idea, why? What's better? Thanks in advance!

Answer 1

I am one of those types who believe that branches are evil. Have a look at this related discussion question on this topic (including the answer yourself): Does it use feature branches compatible with refactoring?

I don’t like the branching of functions because it flies in the face of the central goal of continuous integration (practice, not a tool), which is that developers integrate their work together early and often during the development process and have integrated work confirmed by the automatic build process . By adopting a workflow based on an individual developer, you made this practice impossible by design, and you returned to the developers who made independent, unreasonable changes that should then be combined together into a “big merger” at the end of the development process.

DVCS assistants will say that this is simply a toolbox problem. Now I agree that there are version control systems that handle branching and combine much better than disruptive. Such systems are, of course, suitable for the decentralized open source projects for which they were developed. However, even if the merge was trivially simple (which will never happen, even with ideal tools), you still have the problem of delaying integration until the end of the process. This may be desirable in an open source project in which there are only a few trusted gatekeepers in the trunk and many (less reliable) employees. However, in a commercial team, you really should be able to trust everyone to make a deal with the trunk, and therefore there should be no need for gatekeepers.

In conclusion, here are my answers to your bold questions:

When to branch out? When do you need to unite? I prefer forking for releases, creating a snapshot, and fixing bugs (merging is trivial in this case because you're talking about cherry picking a revision or two between the trunk and release). I generally avoid function branches unless you really need to make large-scale changes to the code base. Each time you have an affiliate, you pay a fine for the “big merger” later.

What is the best approach? In my organization, all developers connect directly to the backbone. We have continuous off trunk assemblies for each application, and we regularly (every week or two) reduce a new release branch (and create a dedicated assembly for each release branch). Instead of creating function branches, we try to create new implementations of our interfaces to implement new or significantly modified functionality. These new implementations may remain unused in production until they are ready, at which time we can switch our applications to their use. Using an IoC container makes this process very easy.

Answer 2

CollabNet, Inc., the original sponsor of Subversion, has put together a list of Subversion Best Practices .

In the last section of the "Know when to create branches" list.

Affiliates depend on the culture of your software project. CollabNet describes three common branch systems.

• Branchless system
• Always-Branch System
• Branch-When Needing System

Never-Branch is used by new projects without executable code. It can also be used by solo developers.

The Always-Branch system is often used by projects that facilitate intensive management and oversight.

Each developer creates / works in a private branch for each coding task. When the encoding is complete, someone or something looks through all the private branch changes and merges them into / trunk.

This system requires more merging when one or more developers make several parallel changes to the module.

Branch-When-Needed is the system used by the Subversion project itself. This is a system that makes sense when a development team releases its product through version control.

Users do their daily work on / trunk. Users do not commit until after unit testing. / Trunk undergoes regression testing on a periodic basis.

Each so often a trunk is labeled with a specific release or version of a product. If an error is detected in a previous version of the product, a branch from the version tag is created to fix the problem. This patch is then merged into / trunk.

Answer 3

To understand when branching is needed, ask yourself why you are entering first.

There are three main reasons you need to branch out:

• You have several versions of your product, and an older version has a defect. In this case, you create a branch with an older version and commit it to the branch. Otherwise, you must include all new code added since release.

• You have dozens of programmers working on a project in version 1.0. As the project approaches the release point, you want to stop adding features and fixing bugs. However, this leaves most of your programmers with nothing to do except twist their thumbs, while the two or three programmers responsible for the release work on completing the release. Just not enough work for everyone. In this case, you release Release 1.0 and release your branch. Meanwhile, other developers can continue to work on version 2.0. \

• You usually have all the developers working on the release and making minor changes. However, there is a big project that will reorganize the structure of your product. If you have developers working on checking your code on the trunk with other developers, you will not be able to compile your assembly and test the changes. Instead, you enter this special project in your own line of code. In this way, backend restructuring is performed on the side branch, while the rest of the development team can continue to work on the trunk.

In the latter case, the team working with the main line must make sure that their code does not lag behind what is happening in the trunk. They should continue to merge the changes in the trunk onto their side branch. Otherwise, the code differences between the side branch and the trunk become too large to be easily merged.

---

The question is why Case No. 3 is much more complicated than in the other two cases. The answer is whether the branches depart from each other or converge to each other. In case No. 1 and case No. 2, the branches diverge. In case No. 2, the code for version 1.0 will be different from the code for version 2.0, and the code for version 1.0 will be different from the code for version 3.0. In fact, sometime in the future, the code in the Release 1.0 branch will be irrelevant.

Meanwhile, in case No. 3, the branches converge strongly to each other. This means that you must synchronize them. This requires effort and supervision. It takes a lot of energy to make sure that the branches that ultimately need to be merged in bulk must remain in sync.

This is why most sites now branch out when necessary and do not use the older feature or development branch system. This adds a lot of complexity. Each branch should be managed, and each merger should be carefully checked.

---

By the way, this is one of the reasons that distributed version control systems are not always better than centralized ones. I saw too many places that Git used, and then the developers worked in their small repository and never talked to each other. A week before the release, we grappled with a dozen patches, and then continue the race to combine all the code into the supplied version.

A centralized repository forces everyone to work on the same set of files. Add to the process of continuous assembly, and you can make sure that there are no surprises. If everyone should work with a centralized repository anyway, the distributed version control system doesn’t really add anything to the mix and can cause problems if you allow developers to live in their small caves.