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 ...


6

If you are going to have the same file in four repos, and allow it to be changed in any of the four places, you will sooner or later run into the problems of collisions, how to work with branches, how to handle commit messages, and so on, for a multi-repo case. Of course, you can try implement some homebrewn solution using SVN hooks, batch scripts and diff/...


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

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 ...


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 ...


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