Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged

59

Some suggestions: There is nothing wrong in having a lot of feature or bugfix branches as long as the changes done in each branch are small enough you can still handle the resulting merge conflicts in an effective manner. That should be your criterion if your way of working is ok, not some MSDN article. Whenever a branch is merged into trunk, the trunk ...


17

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'? Sounds like it. Are some of the problems we're seeing a result of this merge process? Definitely How can we improve this merge process without increasing the bottleneck on my boss? At my company, every dev has the ability to merge. We assign a Merge Request to ...


12

This is essentially how a lot of open source projects work, including most notably the Linux kernel, which has a lot more branches in flight than you do at any given time. The typical way to avoid big bang merges in these projects is to create another branch (or multiple branches) for continuous integration. This is the branch you use to make sure your ...


7

I agree with both Doc Brown but I also see another antipattern: My boss, the sole authority on the trunk repository, will actually defer all of the reviews of branches until a single point in time where he will perform reviews on as much as he can, some branches will be thrown back for enhancements/fixes, some branches will merge right into trunk, some ...


5

Your version control shouldn't matter. This is an issue that should be dealt with at deploy-time. Implement Feature Toggles in your project, controlled by a config file. When you deploy to Country A that needs features X and Y turned on but not Z, your deploy tool provides a configuration file that has X and Y set to true, but Z set to false. And similarly ...


4

In the way of working you describe, there is very little advantage to using branches. With all the merging back and forth, you might as well be working directly on Trunk, except in the (hopefully rare) case that your commit breaks the integration tests. Note that every developer always has a private, local working environment that can be regarded as a kind ...


3

If you have a lot of parallel development consider using a Master branch and feature toggles. It does require some extra discipline to ensure that the build works (even if the feature toggled code is incomplete) and to create, use, and then later cleanup the feature toggles. This can be offset somewhat by having static analysis tools and automated tests to ...


3

OP here. For posterity, I wanted to add what my ultimate solution to this problem was. I will keep the best answer checked, because it's actually the best answer when things go smoothly. First, I tried the selected answer from Doc Brown: https://softwareengineering.stackexchange.com/a/370419/291998 But the svnadmin dump command failed about halfway ...


3

We have one main product and 20-ish clients which have customizations in place This kind of separation is not one that source control is designed to support. You should have one repo per client. Rather than have the entire codebase replicated per client you should change your code, splitting it into as many libraries as possible*, each with its own repo. ...


3

To me, it's a decision between single repo and repo per client. As you also said, the branch per client idea doesn't seem reasonable to me (too complicated, no advantages). Now, I've been working with both approaches, and the advantages of a single repo over multiple repos are to me: Ease of development: one checkout gets all the clients, no need to set up ...


2

I’m going to cut the knot and offer an entirely different solution: Instead of shipping different code for different clients out of different repositories, I would instead unify all the code, ship versions, and control customizations via configurations, or, where there is no conflict between what customers want, ship one client’s customizations as features ...


2

For subversion, it is common to have separated projects in one repository as subdirectories. And, there is no real distinction between branch and subdirectory, so it is only a matter of convention. In most cases it ends up like U1/trunk/ U1/branches/... U1/tags/... F1/trunk/ F1/branches/... F1/tags/... If you have already used root for U1 you could make a ...


2

When you do feature work in separate branches, you can't easily do any integration testing until one of the branches is merged to trunk and pulled into the other feature branches. In my experience, this is the main problem with the Big Bang Merge anti-pattern. Ideally, you would do feature work, test it in the feature branch, merge it into trunk, and at ...


1

How can we improve this merge process without increasing the bottleneck on my boss? Improving the merge process doesn't fix the problem; it will just be an attempt fight the symptoms. And it will be futile, even if you find a way to improve the merge process, if you can't fix your manager, the process will start failing again when you hire a few more ...


1

So you have 20 branches. Branch 1 is just merged. Then the developer of branch 2 has to merge branch 1 into their branch to be able to merge into main without conflict, then merges. Then the developer of branch 3 has to merge branch 1 and branch 2 into their branch to be able to merge into main without conflict, then merges. Exercise for the reader: Write ...


1

I've seen attempts to segregate workflows based on user experience/trust/risk evaluations, with questionable results: everyone makes mistakes the more seasoned developers usually tackle significantly more difficult/complex problems than the mentored developers, often with higher chances of causing regressions I wouldn't recommend extending the workflow ...


Only top voted, non community-wiki answers of a minimum length are eligible