Is my company merging branches wrong?How can I avoid editing conflicts repeatedly when merging from one to branch to another?TFS Branching AdviceShould I merge from the same branch or from a merge?Merging branches where the same code was worked onProper sequence of actions for merging using SVN?Merging from unfinished feature branches and code reviewSVN best practices - different code logic in branchesShould developers merge code across branches?

Did the US push the Kurds to lower their defences against Turkey in the months preceding the latest Turkish military operation against them?

Sci fi book, Jesus returns in the 1950's and the 1980's

Tear in RFs, not losing air

If you revoke a certificate authority's certificate, do all of the certificates it issued become invalid as well?

Is it possible for a country to develop the equivalent of a Second Industrial Revolution while under a war of attrition?

Is it allowed to let the engine of an aircraft idle without a pilot in the plane. (For both helicopters and aeroplanes)

How long does it take to sail to Evermeet from the Neverwinter harbor?

In the old name Dreadnought, is nought an adverb or a noun?

Word for 'most late'

What would be the effect of a giant magical fireball burning in the ocean?

Where are the uarts on the raspberry pi 4?

Who inspired the character Geordi La Forge?

Russian Caesar cipher

What is this "very, very powerful article" that Trump is referring to vis à vis the Kurds?

Tube Patch or tubeless plug

Labeling lines that are not within polygons using field calculator

Can Microsoft employees see my data?

Is the tap water in France safe to drink?

How are Aircraft Noses Designed?

Prisoner's dilemma formulation for children

Should I respond to a sabotage accusation e-mail at work?

2000's spooky show with a group of teens telling spooky stories in the woods

How do I get my boyfriend to remove pictures of his ex girlfriend hanging in his apartment?

In the twin paradox does the returning twin also come back permanently length contracted flatter than the twin on Earth?

Is my company merging branches wrong?

How can I avoid editing conflicts repeatedly when merging from one to branch to another?TFS Branching AdviceShould I merge from the same branch or from a merge?Merging branches where the same code was worked onProper sequence of actions for merging using SVN?Merging from unfinished feature branches and code reviewSVN best practices - different code logic in branchesShould developers merge code across branches?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;

I recently came across an MSDN article about branching and merging and SCM: Branching and Merging Primer - Chris Birmele.

In the article they say 'big bang merge' is a merging antipattern:

Big Bang Merge — deferring branch merging to the end of the
development effort and attempting to merge all branches
simultaneously.

I realized that this is very similar to what my company is doing with all of the development branches that are produced.

I work at a very small company with one person acting as the final review + trunk merge authority. We have 5 developers (including me), each of us will be assigned a separate task/bug/project and we will each branch off the current trunk (subversion) and then perform the development work in our branch, test the results, write documentation if necessary, perform a peer review and feedback loop with the other developers, and then submit the branch for review + merge on our project management software.

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 branches will be thrown back because of conflicts, etc.

It's not uncommon for us to have 10-20 active branches sitting in the final review queue to be merged into trunk.

We also frequently have to resolve conflicts in the final review and merge stage because two branches were created off the same trunk but modified the same piece of code. Usually we avoid this by just rebranching off trunk and re-applying our changes and resolving the conflicts then submitting the new branch for review (poor mans rebase).

Some direct questions I have are:

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'?

Are some of the problems we're seeing a result of this merge process?

How can we improve this merge process without increasing the bottleneck on my boss?

Edit: I doubt my boss will loosen his grip on the trunk repository, or allow other devs to merge to trunk. Not sure what his reasons for that are but I don't really plan on bringing the topic up because it's been brought up before and shot down rather quickly. I think they just don't trust us, which doesn't make sense because everything is tracked anyway.

Any other insight into this situation would be appreciated.

edited May 17 at 6:03

muru

1237 bronze badges

asked May 16 at 18:52

user6567423

1692 silver badges8 bronze badges

2

Why is merging deferred? Usually, there is a reason for not doing it immediately. is the single guy overworked and the backlog just gets so big? is there some other reason why merging isn't done in a timely manner?

– Polygnome
May 17 at 4:42

1

I was in a similar position as you, several times. I can tell from personal experience that many companies do version control, especially branching, horribly wrong.

– MechMK1
May 17 at 11:14

2

What happens when the boss goes on holiday?

– Liath
May 17 at 13:28

How would you define the linux kernel branching/merge strategy?

– Braiam
May 17 at 15:04

Do the changes that are thrown back because of conflicts but not other defects need to go through the approval process again once the conflicts are resolved or are they considered "provisionally approved"?

– Gregory Nisbet
May 17 at 16:19

|
show 6 more comments

I recently came across an MSDN article about branching and merging and SCM: Branching and Merging Primer - Chris Birmele.

In the article they say 'big bang merge' is a merging antipattern:

Big Bang Merge — deferring branch merging to the end of the
development effort and attempting to merge all branches
simultaneously.

I realized that this is very similar to what my company is doing with all of the development branches that are produced.

It's not uncommon for us to have 10-20 active branches sitting in the final review queue to be merged into trunk.

Some direct questions I have are:

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'?

Are some of the problems we're seeing a result of this merge process?

How can we improve this merge process without increasing the bottleneck on my boss?

Any other insight into this situation would be appreciated.

edited May 17 at 6:03

muru

1237 bronze badges

asked May 16 at 18:52

user6567423

1692 silver badges8 bronze badges

2

Why is merging deferred? Usually, there is a reason for not doing it immediately. is the single guy overworked and the backlog just gets so big? is there some other reason why merging isn't done in a timely manner?

– Polygnome
May 17 at 4:42

1

I was in a similar position as you, several times. I can tell from personal experience that many companies do version control, especially branching, horribly wrong.

– MechMK1
May 17 at 11:14

2

What happens when the boss goes on holiday?

– Liath
May 17 at 13:28

How would you define the linux kernel branching/merge strategy?

– Braiam
May 17 at 15:04

Do the changes that are thrown back because of conflicts but not other defects need to go through the approval process again once the conflicts are resolved or are they considered "provisionally approved"?

– Gregory Nisbet
May 17 at 16:19

|
show 6 more comments

I recently came across an MSDN article about branching and merging and SCM: Branching and Merging Primer - Chris Birmele.

In the article they say 'big bang merge' is a merging antipattern:

Big Bang Merge — deferring branch merging to the end of the
development effort and attempting to merge all branches
simultaneously.

I realized that this is very similar to what my company is doing with all of the development branches that are produced.

It's not uncommon for us to have 10-20 active branches sitting in the final review queue to be merged into trunk.

Some direct questions I have are:

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'?

Are some of the problems we're seeing a result of this merge process?

How can we improve this merge process without increasing the bottleneck on my boss?

Any other insight into this situation would be appreciated.

edited May 17 at 6:03

muru

1237 bronze badges

asked May 16 at 18:52

user6567423

1692 silver badges8 bronze badges

I recently came across an MSDN article about branching and merging and SCM: Branching and Merging Primer - Chris Birmele.

In the article they say 'big bang merge' is a merging antipattern:

Big Bang Merge — deferring branch merging to the end of the
development effort and attempting to merge all branches
simultaneously.

I realized that this is very similar to what my company is doing with all of the development branches that are produced.

It's not uncommon for us to have 10-20 active branches sitting in the final review queue to be merged into trunk.

Some direct questions I have are:

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'?

Are some of the problems we're seeing a result of this merge process?

How can we improve this merge process without increasing the bottleneck on my boss?

Any other insight into this situation would be appreciated.

svn anti-patterns merging scm

edited May 17 at 6:03

muru

1237 bronze badges

asked May 16 at 18:52

user6567423

1692 silver badges8 bronze badges

edited May 17 at 6:03

muru

1237 bronze badges

asked May 16 at 18:52

user6567423

1692 silver badges8 bronze badges

edited May 17 at 6:03

muru

1237 bronze badges

edited May 17 at 6:03

muru

1237 bronze badges

edited May 17 at 6:03

muru

1237 bronze badges

asked May 16 at 18:52

user6567423

1692 silver badges8 bronze badges

asked May 16 at 18:52

user6567423

1692 silver badges8 bronze badges

asked May 16 at 18:52

user6567423

1692 silver badges8 bronze badges

2

Why is merging deferred? Usually, there is a reason for not doing it immediately. is the single guy overworked and the backlog just gets so big? is there some other reason why merging isn't done in a timely manner?

– Polygnome
May 17 at 4:42

1

I was in a similar position as you, several times. I can tell from personal experience that many companies do version control, especially branching, horribly wrong.

– MechMK1
May 17 at 11:14

2

What happens when the boss goes on holiday?

– Liath
May 17 at 13:28

How would you define the linux kernel branching/merge strategy?

– Braiam
May 17 at 15:04

Do the changes that are thrown back because of conflicts but not other defects need to go through the approval process again once the conflicts are resolved or are they considered "provisionally approved"?

– Gregory Nisbet
May 17 at 16:19

|
show 6 more comments

2

Why is merging deferred? Usually, there is a reason for not doing it immediately. is the single guy overworked and the backlog just gets so big? is there some other reason why merging isn't done in a timely manner?

– Polygnome
May 17 at 4:42

1

I was in a similar position as you, several times. I can tell from personal experience that many companies do version control, especially branching, horribly wrong.

– MechMK1
May 17 at 11:14

2

What happens when the boss goes on holiday?

– Liath
May 17 at 13:28

How would you define the linux kernel branching/merge strategy?

– Braiam
May 17 at 15:04

Do the changes that are thrown back because of conflicts but not other defects need to go through the approval process again once the conflicts are resolved or are they considered "provisionally approved"?

– Gregory Nisbet
May 17 at 16:19

Why is merging deferred? Usually, there is a reason for not doing it immediately. is the single guy overworked and the backlog just gets so big? is there some other reason why merging isn't done in a timely manner?

– Polygnome
May 17 at 4:42

I was in a similar position as you, several times. I can tell from personal experience that many companies do version control, especially branching, horribly wrong.

– MechMK1
May 17 at 11:14

What happens when the boss goes on holiday?

– Liath
May 17 at 13:28

How would you define the linux kernel branching/merge strategy?

– Braiam
May 17 at 15:04

Do the changes that are thrown back because of conflicts but not other defects need to go through the approval process again once the conflicts are resolved or are they considered "provisionally approved"?

– Gregory Nisbet
May 17 at 16:19

|
show 6 more comments

7 Answers
7

active

oldest

votes

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 should be merged into all open development branches ASAP. This would allow all people in the team to resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk.

This would work way better if the gatekeeper would not wait until 10 branches are "ready for merging into trunk" - resolving merge conflicts from the last trunk integrations always needs some time for the team, so it is probably better to work in interwoven time intervals - one integration by the gatekeeper, one re-merge by the team, next integration by the gatekeeper, next re-merge by the team, and so on.

To keep branches small, it might help to split larger features into several smaller tasks and develop each of those tasks in a branch of its own. If the feature is not production ready until all subtasks are implemented, hide it from production behind a feature toggle until all subtasks are completed.

Sooner or later you will encounter refactoring tasks which affect many files in the code base - these have a high risk of causing a lot merge conflicts with many branches. Those can be handled best by communicating them clearly in the team, and make sure to handle them exactly as I wrote above: by integrating them first into all dev branches before reintegration, and by splitting them up into smaller sub-refactorings.

For your current team size, having a single gatekeeper may still work. But if your team will grow in size, there is no way around having a second gatekeeper (or more). Note I am not suggesting to allow everyone to merge into trunk, but that does not mean only your boss is capable of doing this. There are probably one or two senior devs who could be candidates for doing the gatekeeper's job, too. And even for your current team's size, a second gatekeeper could make it easier for your team to integrate to the trunk more often and earlier, or when your boss is not available.

edited May 19 at 12:47

answered May 16 at 21:27

Doc Brown

145k25 gold badges270 silver badges427 bronze badges

2

I think you have the best comment here, acknowledging that we cannot simply open trunk to everybody, and that our stack of branches isn't exactly always a problem (only when they conflict). I think you did a good job pointing out how we can reduce conflicts and ensure the merge cycle is smooth, I also think you are completely correct when you say we may need another gatekeeper. Thanks a lot for this insight!

– user6567423
May 16 at 23:19

@user6567423 Another thing you might want to consider is making branches for each development version (e.g. 5.2.3 or whatever), that each developer can branch off of for feature work and then merge onto, and which can then be merged back onto the main release branch by the boss when development is complete.

– nick012000
May 17 at 4:57

@nick012000: would that suggestion not make it harder for the gatekeeper to accept or reject individidual feature branches for / against integration into trunk? I mean, if several features are mixed up into one development branch, reintegrating those changes partly into trunk would become really hard. Or am I missing something?

– Doc Brown
May 17 at 6:35

9

"resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk." - I feel like this part is unjustly reduced to a side note. "It's better for the company BUT ALSO easier for you" seems like the main selling point when suggesting this to the boss. That goes more into the direction office politics, which SE isn't about - but in this situation, without buy-in from the boss, everything else in this technically excellent answer just won't happen.

– R. Schmitz
May 17 at 9:32

@DocBrown Yeah, it would, but it would also mean that you’d have a lot less conflicts between the dev branches and it’d still give you the degree of safety given by not directly merging onto the main branch - and he can simply decline to accept the work as Done and perform the merge until he’s happy with the state of the code as a whole.

– nick012000
May 17 at 9:41

|
show 1 more comment

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 another dev, go through the review/feedback/update cycle until both parties are satisfied. Then the reviewer merges the code.

10-20 branches waiting to get merged is a sign that your process is flawed. If we had that many, all dev work would stop until it was cleared up.

answered May 16 at 19:31

Matthew

8472 silver badges8 bronze badges

1

Not the answer I was looking for because I doubt my boss is going to loosen his grip on the trunk repository. But an incredibly helpful answer none-the-less, thanks for the insight!

– user6567423
May 16 at 19:34

4

@user6567423: If your boss becomes the bottleneck, which he now is according to your description, he's going to have to either change his approach or accept that he's the cause for delays (which his employees then cannot be blamed for). Refusing to change your approach, ignoring the problems you're creating, and pushing the blame onto others are no way of running a business.

– Flater
May 17 at 13:14

1

He does agree that he is the bottleneck and he most certainly does not blame others for it. But yes, I was looking for any tips that might not be readily obvious that could possibly reduce our bottleneck. Thanks for the insight

– user6567423
May 17 at 18:23

@user6567423 I'm curious if he has ever explained why he's the only one who can merge to trunk.

– Matthew
May 18 at 2:05

add a comment
|

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 changes work together with your colleagues, and it gets periodically rebased onto the trunk when the gatekeeper gets around to doing reviews.

Optionally, you can use this branch to combine several of your own pull requests into one big cohesive request for your boss to review. Linus Torvalds typically gets pull requests that have been integrated two or more levels deep, and can have a size on the order of, for example, a complete new filesystem driver.

answered May 16 at 20:17

Karl Bielefeldt

124k34 gold badges229 silver badges427 bronze badges

Thanks I think the tips on combining branches and preventing conflicts will probably be our best course of action.

– user6567423
May 16 at 20:29

add a comment
|

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 branches will be thrown back because of conflicts, etc.

In my humble there are some management antipatterns:

He/she is the single choke point constraining the velocity of the team. Your bus factor is 1. The theory of constraints say that you should put your effort in improving the slowest part of chain.

Your manager is making your feedback cycle slower and reducing the agility of your team. Can you release every week?

Merges complexity grow exponentially with the amount of code. It is better to make 10 merges with 100 lines than 1 of 1000 lines. That is just one of the reasons why you should do it ASAP

If you detect a failure in the trunk you will do it latter in time. Which of the several branches was the problematic one

Decissions should be made by those who have more knoledge about them. Who knows more in this case? I bet that the developers that made the code.

You can't fix a bug in production if your manager is on holydays.

You are redoing work and throwing back branches. This is a waste of time. The time it is waiting to reach production is also waste.

Recomendations:

Your manager needs to delegate responsability to the team. You need
to show that the team is mature, professional. Make clear that they
can trust in the team

Implement some review method. May be you need the aproval of two other team members.

May be using SVN is making it harder. Give Git a try and see if it helps you. Even more. If you use GitHub you can use the Pull Request mechanism so that a merge requires certain votes.

Read and share information about agile practices, continous integration and DevOps.

edited May 17 at 13:07

answered May 17 at 9:38

Borjab

9845 silver badges15 bronze badges

7

I've worked professionally with both SVN and git, and I'd say that SVN is definitely part of the problem: It forces a single-merge-back-commit policy on branches which is not present in git. In git, all merges are equal, in SVN, some are more equal than others. Also, the lack of local commits makes it much harder to experiment with SVN than with git, and the lack of a staging zone only adds to the inflexibility of SVN. There's a reason why Torvalds did not just use SVN instead of developing git...

– cmaster
May 17 at 12:49

Git is so much better than svn in my opinion for the reasons @cmaster laid out and more

– reggaeguitar
May 17 at 15:43

I agree git would probably solve some of our merging problems, and dear god would I love to have rebase available. But I don't think we're going to make the switch anytime soon :(

– user6567423
May 17 at 18:25

1

@user6567423, I did a consultation last year where I helped a small team transition from svn to Git and change their workflow over, including training them on Git and setting them up with GitLab community edition (which is open source) for code reviews and collaboration. They were very enthusiastic about it; it was a night and day difference. (Also it took only three days.)

– Wildcard
May 17 at 20:03

add a comment
|

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 that point you are done with the feature. If it hasn't been merged, you have to revisit it each time something else is merged into trunk before it. The pain of this anti-pattern is that you have a lot of integration-type bugs showing up at the end of the development cycle.

answered May 17 at 0:28

bmm6o

1291 bronze badge

add a comment
|

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 a program that prints my complete post :-)

This is madness. You will be spending an incredible amount of time merging.

answered May 16 at 19:36

gnasher729

22.9k2 gold badges34 silver badges69 bronze badges

Well not necessarily, unless the branches are in conflict then he can just merge them all into trunk seamlessly. We will usually try to prevent any conflicts by doing a test merge before we submit the branch for review but the conflicts come up inevitably as the number of branches in the queue increases. I do agree that it sounds like madness though.

– user6567423
May 16 at 19:38

2

Normal SVN merging behavior, as far as I can tell...

– cmaster
May 17 at 12:51

add a comment
|

Given the way you are working and that your boss is a responsible control freak, branching itself seems to be the problem. Rather than creating a branch for every feature, have each developer commit his feature in parts, directly into the trunk. This puts the burden of integration on the developer in multiple smaller steps (win-win). Gate keeper can keep up with tracking smaller changes over a longer period earlier in the development cycle and still be the master reviewer.

Branching itself is something you do not want to do unless you have a very good reason to do it or you have no other option. You are small enough to keep things in sync more tightly, which will be easier and safer.

edited May 17 at 18:00

answered May 17 at 5:12

Martin Maat

9,9843 gold badges14 silver badges40 bronze badges

1

And how are you going to handle the release if just 1 of those features has a bug or isn't finished in time? "Branching itself is something you do not want to do unless you have a very good reason to do" -- Once you have 5 people working on multiple features each, you have to use branching unless you have a very very good reason not to.

– Ivo van der Veeken
May 17 at 12:53

It was about two thing: boss wants to remain the one and only gate keeper and things are not supposed to diverge too much. Yes, there will be a moment at which something was pushed that is yet to be scrutinized by boss. He should be able to do that quickly though and in the unlikely event he needs to deliver immediately he can revert the latest commits. This will keep things in sync and if you fail at anything you will certainly fail fast. Looks like a good compromise to me for the situation at hand.

– Martin Maat
May 17 at 13:23

1

I would consider this as a last resort

– reggaeguitar
May 17 at 15:45

add a comment
|

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "131"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f391987%2fis-my-company-merging-branches-wrong%23new-answer', 'question_page');

);

Post as a guest

Name

Required, but never shown

StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function ()
$("#show-editor-button").addClass("d-none");
$("#post-form").removeClass("d-none");
StackExchange.editor.finallyInit();
;

var useFancy = $(this).data('confirm-use-fancy');
if (useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');

$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function (popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');

pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);

)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();

);
);

7 Answers
7

active

oldest

votes

7 Answers
7

active

oldest

votes

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 should be merged into all open development branches ASAP. This would allow all people in the team to resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk.

This would work way better if the gatekeeper would not wait until 10 branches are "ready for merging into trunk" - resolving merge conflicts from the last trunk integrations always needs some time for the team, so it is probably better to work in interwoven time intervals - one integration by the gatekeeper, one re-merge by the team, next integration by the gatekeeper, next re-merge by the team, and so on.

To keep branches small, it might help to split larger features into several smaller tasks and develop each of those tasks in a branch of its own. If the feature is not production ready until all subtasks are implemented, hide it from production behind a feature toggle until all subtasks are completed.

Sooner or later you will encounter refactoring tasks which affect many files in the code base - these have a high risk of causing a lot merge conflicts with many branches. Those can be handled best by communicating them clearly in the team, and make sure to handle them exactly as I wrote above: by integrating them first into all dev branches before reintegration, and by splitting them up into smaller sub-refactorings.

For your current team size, having a single gatekeeper may still work. But if your team will grow in size, there is no way around having a second gatekeeper (or more). Note I am not suggesting to allow everyone to merge into trunk, but that does not mean only your boss is capable of doing this. There are probably one or two senior devs who could be candidates for doing the gatekeeper's job, too. And even for your current team's size, a second gatekeeper could make it easier for your team to integrate to the trunk more often and earlier, or when your boss is not available.

edited May 19 at 12:47

answered May 16 at 21:27

Doc Brown

145k25 gold badges270 silver badges427 bronze badges

2

I think you have the best comment here, acknowledging that we cannot simply open trunk to everybody, and that our stack of branches isn't exactly always a problem (only when they conflict). I think you did a good job pointing out how we can reduce conflicts and ensure the merge cycle is smooth, I also think you are completely correct when you say we may need another gatekeeper. Thanks a lot for this insight!

– user6567423
May 16 at 23:19

@user6567423 Another thing you might want to consider is making branches for each development version (e.g. 5.2.3 or whatever), that each developer can branch off of for feature work and then merge onto, and which can then be merged back onto the main release branch by the boss when development is complete.

– nick012000
May 17 at 4:57

@nick012000: would that suggestion not make it harder for the gatekeeper to accept or reject individidual feature branches for / against integration into trunk? I mean, if several features are mixed up into one development branch, reintegrating those changes partly into trunk would become really hard. Or am I missing something?

– Doc Brown
May 17 at 6:35

9

"resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk." - I feel like this part is unjustly reduced to a side note. "It's better for the company BUT ALSO easier for you" seems like the main selling point when suggesting this to the boss. That goes more into the direction office politics, which SE isn't about - but in this situation, without buy-in from the boss, everything else in this technically excellent answer just won't happen.

– R. Schmitz
May 17 at 9:32

@DocBrown Yeah, it would, but it would also mean that you’d have a lot less conflicts between the dev branches and it’d still give you the degree of safety given by not directly merging onto the main branch - and he can simply decline to accept the work as Done and perform the merge until he’s happy with the state of the code as a whole.

– nick012000
May 17 at 9:41

|
show 1 more comment

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 should be merged into all open development branches ASAP. This would allow all people in the team to resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk.

This would work way better if the gatekeeper would not wait until 10 branches are "ready for merging into trunk" - resolving merge conflicts from the last trunk integrations always needs some time for the team, so it is probably better to work in interwoven time intervals - one integration by the gatekeeper, one re-merge by the team, next integration by the gatekeeper, next re-merge by the team, and so on.

To keep branches small, it might help to split larger features into several smaller tasks and develop each of those tasks in a branch of its own. If the feature is not production ready until all subtasks are implemented, hide it from production behind a feature toggle until all subtasks are completed.

Sooner or later you will encounter refactoring tasks which affect many files in the code base - these have a high risk of causing a lot merge conflicts with many branches. Those can be handled best by communicating them clearly in the team, and make sure to handle them exactly as I wrote above: by integrating them first into all dev branches before reintegration, and by splitting them up into smaller sub-refactorings.

For your current team size, having a single gatekeeper may still work. But if your team will grow in size, there is no way around having a second gatekeeper (or more). Note I am not suggesting to allow everyone to merge into trunk, but that does not mean only your boss is capable of doing this. There are probably one or two senior devs who could be candidates for doing the gatekeeper's job, too. And even for your current team's size, a second gatekeeper could make it easier for your team to integrate to the trunk more often and earlier, or when your boss is not available.

edited May 19 at 12:47

answered May 16 at 21:27

Doc Brown

145k25 gold badges270 silver badges427 bronze badges

2

I think you have the best comment here, acknowledging that we cannot simply open trunk to everybody, and that our stack of branches isn't exactly always a problem (only when they conflict). I think you did a good job pointing out how we can reduce conflicts and ensure the merge cycle is smooth, I also think you are completely correct when you say we may need another gatekeeper. Thanks a lot for this insight!

– user6567423
May 16 at 23:19

@user6567423 Another thing you might want to consider is making branches for each development version (e.g. 5.2.3 or whatever), that each developer can branch off of for feature work and then merge onto, and which can then be merged back onto the main release branch by the boss when development is complete.

– nick012000
May 17 at 4:57

@nick012000: would that suggestion not make it harder for the gatekeeper to accept or reject individidual feature branches for / against integration into trunk? I mean, if several features are mixed up into one development branch, reintegrating those changes partly into trunk would become really hard. Or am I missing something?

– Doc Brown
May 17 at 6:35

9

"resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk." - I feel like this part is unjustly reduced to a side note. "It's better for the company BUT ALSO easier for you" seems like the main selling point when suggesting this to the boss. That goes more into the direction office politics, which SE isn't about - but in this situation, without buy-in from the boss, everything else in this technically excellent answer just won't happen.

– R. Schmitz
May 17 at 9:32

@DocBrown Yeah, it would, but it would also mean that you’d have a lot less conflicts between the dev branches and it’d still give you the degree of safety given by not directly merging onto the main branch - and he can simply decline to accept the work as Done and perform the merge until he’s happy with the state of the code as a whole.

– nick012000
May 17 at 9:41

|
show 1 more comment

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 should be merged into all open development branches ASAP. This would allow all people in the team to resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk.

This would work way better if the gatekeeper would not wait until 10 branches are "ready for merging into trunk" - resolving merge conflicts from the last trunk integrations always needs some time for the team, so it is probably better to work in interwoven time intervals - one integration by the gatekeeper, one re-merge by the team, next integration by the gatekeeper, next re-merge by the team, and so on.

To keep branches small, it might help to split larger features into several smaller tasks and develop each of those tasks in a branch of its own. If the feature is not production ready until all subtasks are implemented, hide it from production behind a feature toggle until all subtasks are completed.

Sooner or later you will encounter refactoring tasks which affect many files in the code base - these have a high risk of causing a lot merge conflicts with many branches. Those can be handled best by communicating them clearly in the team, and make sure to handle them exactly as I wrote above: by integrating them first into all dev branches before reintegration, and by splitting them up into smaller sub-refactorings.

For your current team size, having a single gatekeeper may still work. But if your team will grow in size, there is no way around having a second gatekeeper (or more). Note I am not suggesting to allow everyone to merge into trunk, but that does not mean only your boss is capable of doing this. There are probably one or two senior devs who could be candidates for doing the gatekeeper's job, too. And even for your current team's size, a second gatekeeper could make it easier for your team to integrate to the trunk more often and earlier, or when your boss is not available.

edited May 19 at 12:47

answered May 16 at 21:27

Doc Brown

145k25 gold badges270 silver badges427 bronze badges

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 should be merged into all open development branches ASAP. This would allow all people in the team to resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk.

This would work way better if the gatekeeper would not wait until 10 branches are "ready for merging into trunk" - resolving merge conflicts from the last trunk integrations always needs some time for the team, so it is probably better to work in interwoven time intervals - one integration by the gatekeeper, one re-merge by the team, next integration by the gatekeeper, next re-merge by the team, and so on.

To keep branches small, it might help to split larger features into several smaller tasks and develop each of those tasks in a branch of its own. If the feature is not production ready until all subtasks are implemented, hide it from production behind a feature toggle until all subtasks are completed.

Sooner or later you will encounter refactoring tasks which affect many files in the code base - these have a high risk of causing a lot merge conflicts with many branches. Those can be handled best by communicating them clearly in the team, and make sure to handle them exactly as I wrote above: by integrating them first into all dev branches before reintegration, and by splitting them up into smaller sub-refactorings.

For your current team size, having a single gatekeeper may still work. But if your team will grow in size, there is no way around having a second gatekeeper (or more). Note I am not suggesting to allow everyone to merge into trunk, but that does not mean only your boss is capable of doing this. There are probably one or two senior devs who could be candidates for doing the gatekeeper's job, too. And even for your current team's size, a second gatekeeper could make it easier for your team to integrate to the trunk more often and earlier, or when your boss is not available.

edited May 19 at 12:47

answered May 16 at 21:27

Doc Brown

145k25 gold badges270 silver badges427 bronze badges

edited May 19 at 12:47

answered May 16 at 21:27

Doc Brown

145k25 gold badges270 silver badges427 bronze badges

answered May 16 at 21:27

Doc Brown

145k25 gold badges270 silver badges427 bronze badges

answered May 16 at 21:27

Doc Brown

145k25 gold badges270 silver badges427 bronze badges

2

I think you have the best comment here, acknowledging that we cannot simply open trunk to everybody, and that our stack of branches isn't exactly always a problem (only when they conflict). I think you did a good job pointing out how we can reduce conflicts and ensure the merge cycle is smooth, I also think you are completely correct when you say we may need another gatekeeper. Thanks a lot for this insight!

– user6567423
May 16 at 23:19

@user6567423 Another thing you might want to consider is making branches for each development version (e.g. 5.2.3 or whatever), that each developer can branch off of for feature work and then merge onto, and which can then be merged back onto the main release branch by the boss when development is complete.

– nick012000
May 17 at 4:57

@nick012000: would that suggestion not make it harder for the gatekeeper to accept or reject individidual feature branches for / against integration into trunk? I mean, if several features are mixed up into one development branch, reintegrating those changes partly into trunk would become really hard. Or am I missing something?

– Doc Brown
May 17 at 6:35

9

"resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk." - I feel like this part is unjustly reduced to a side note. "It's better for the company BUT ALSO easier for you" seems like the main selling point when suggesting this to the boss. That goes more into the direction office politics, which SE isn't about - but in this situation, without buy-in from the boss, everything else in this technically excellent answer just won't happen.

– R. Schmitz
May 17 at 9:32

@DocBrown Yeah, it would, but it would also mean that you’d have a lot less conflicts between the dev branches and it’d still give you the degree of safety given by not directly merging onto the main branch - and he can simply decline to accept the work as Done and perform the merge until he’s happy with the state of the code as a whole.

– nick012000
May 17 at 9:41

|
show 1 more comment

2

I think you have the best comment here, acknowledging that we cannot simply open trunk to everybody, and that our stack of branches isn't exactly always a problem (only when they conflict). I think you did a good job pointing out how we can reduce conflicts and ensure the merge cycle is smooth, I also think you are completely correct when you say we may need another gatekeeper. Thanks a lot for this insight!

– user6567423
May 16 at 23:19

@user6567423 Another thing you might want to consider is making branches for each development version (e.g. 5.2.3 or whatever), that each developer can branch off of for feature work and then merge onto, and which can then be merged back onto the main release branch by the boss when development is complete.

– nick012000
May 17 at 4:57

@nick012000: would that suggestion not make it harder for the gatekeeper to accept or reject individidual feature branches for / against integration into trunk? I mean, if several features are mixed up into one development branch, reintegrating those changes partly into trunk would become really hard. Or am I missing something?

– Doc Brown
May 17 at 6:35

9

"resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk." - I feel like this part is unjustly reduced to a side note. "It's better for the company BUT ALSO easier for you" seems like the main selling point when suggesting this to the boss. That goes more into the direction office politics, which SE isn't about - but in this situation, without buy-in from the boss, everything else in this technically excellent answer just won't happen.

– R. Schmitz
May 17 at 9:32

@DocBrown Yeah, it would, but it would also mean that you’d have a lot less conflicts between the dev branches and it’d still give you the degree of safety given by not directly merging onto the main branch - and he can simply decline to accept the work as Done and perform the merge until he’s happy with the state of the code as a whole.

– nick012000
May 17 at 9:41

I think you have the best comment here, acknowledging that we cannot simply open trunk to everybody, and that our stack of branches isn't exactly always a problem (only when they conflict). I think you did a good job pointing out how we can reduce conflicts and ensure the merge cycle is smooth, I also think you are completely correct when you say we may need another gatekeeper. Thanks a lot for this insight!

– user6567423
May 16 at 23:19

@user6567423 Another thing you might want to consider is making branches for each development version (e.g. 5.2.3 or whatever), that each developer can branch off of for feature work and then merge onto, and which can then be merged back onto the main release branch by the boss when development is complete.

– nick012000
May 17 at 4:57

@nick012000: would that suggestion not make it harder for the gatekeeper to accept or reject individidual feature branches for / against integration into trunk? I mean, if several features are mixed up into one development branch, reintegrating those changes partly into trunk would become really hard. Or am I missing something?

– Doc Brown
May 17 at 6:35

"resolve merge conflicts in parallel in their own branch and so take some burden from the gatekeeper of the trunk." - I feel like this part is unjustly reduced to a side note. "It's better for the company BUT ALSO easier for you" seems like the main selling point when suggesting this to the boss. That goes more into the direction office politics, which SE isn't about - but in this situation, without buy-in from the boss, everything else in this technically excellent answer just won't happen.

– R. Schmitz
May 17 at 9:32

@DocBrown Yeah, it would, but it would also mean that you’d have a lot less conflicts between the dev branches and it’d still give you the degree of safety given by not directly merging onto the main branch - and he can simply decline to accept the work as Done and perform the merge until he’s happy with the state of the code as a whole.

– nick012000
May 17 at 9:41

|
show 1 more comment

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?

10-20 branches waiting to get merged is a sign that your process is flawed. If we had that many, all dev work would stop until it was cleared up.

answered May 16 at 19:31

Matthew

8472 silver badges8 bronze badges

1

Not the answer I was looking for because I doubt my boss is going to loosen his grip on the trunk repository. But an incredibly helpful answer none-the-less, thanks for the insight!

– user6567423
May 16 at 19:34

4

@user6567423: If your boss becomes the bottleneck, which he now is according to your description, he's going to have to either change his approach or accept that he's the cause for delays (which his employees then cannot be blamed for). Refusing to change your approach, ignoring the problems you're creating, and pushing the blame onto others are no way of running a business.

– Flater
May 17 at 13:14

1

He does agree that he is the bottleneck and he most certainly does not blame others for it. But yes, I was looking for any tips that might not be readily obvious that could possibly reduce our bottleneck. Thanks for the insight

– user6567423
May 17 at 18:23

@user6567423 I'm curious if he has ever explained why he's the only one who can merge to trunk.

– Matthew
May 18 at 2:05

add a comment
|

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?

10-20 branches waiting to get merged is a sign that your process is flawed. If we had that many, all dev work would stop until it was cleared up.

answered May 16 at 19:31

Matthew

8472 silver badges8 bronze badges

1

Not the answer I was looking for because I doubt my boss is going to loosen his grip on the trunk repository. But an incredibly helpful answer none-the-less, thanks for the insight!

– user6567423
May 16 at 19:34

4

@user6567423: If your boss becomes the bottleneck, which he now is according to your description, he's going to have to either change his approach or accept that he's the cause for delays (which his employees then cannot be blamed for). Refusing to change your approach, ignoring the problems you're creating, and pushing the blame onto others are no way of running a business.

– Flater
May 17 at 13:14

1

He does agree that he is the bottleneck and he most certainly does not blame others for it. But yes, I was looking for any tips that might not be readily obvious that could possibly reduce our bottleneck. Thanks for the insight

– user6567423
May 17 at 18:23

@user6567423 I'm curious if he has ever explained why he's the only one who can merge to trunk.

– Matthew
May 18 at 2:05

add a comment
|

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?

10-20 branches waiting to get merged is a sign that your process is flawed. If we had that many, all dev work would stop until it was cleared up.

answered May 16 at 19:31

Matthew

8472 silver badges8 bronze badges

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?

10-20 branches waiting to get merged is a sign that your process is flawed. If we had that many, all dev work would stop until it was cleared up.

answered May 16 at 19:31

Matthew

8472 silver badges8 bronze badges

answered May 16 at 19:31

Matthew

8472 silver badges8 bronze badges

answered May 16 at 19:31

Matthew

8472 silver badges8 bronze badges

answered May 16 at 19:31

Matthew

8472 silver badges8 bronze badges

1

Not the answer I was looking for because I doubt my boss is going to loosen his grip on the trunk repository. But an incredibly helpful answer none-the-less, thanks for the insight!

– user6567423
May 16 at 19:34

4

@user6567423: If your boss becomes the bottleneck, which he now is according to your description, he's going to have to either change his approach or accept that he's the cause for delays (which his employees then cannot be blamed for). Refusing to change your approach, ignoring the problems you're creating, and pushing the blame onto others are no way of running a business.

– Flater
May 17 at 13:14

1

He does agree that he is the bottleneck and he most certainly does not blame others for it. But yes, I was looking for any tips that might not be readily obvious that could possibly reduce our bottleneck. Thanks for the insight

– user6567423
May 17 at 18:23

@user6567423 I'm curious if he has ever explained why he's the only one who can merge to trunk.

– Matthew
May 18 at 2:05

add a comment
|

1

Not the answer I was looking for because I doubt my boss is going to loosen his grip on the trunk repository. But an incredibly helpful answer none-the-less, thanks for the insight!

– user6567423
May 16 at 19:34

4

@user6567423: If your boss becomes the bottleneck, which he now is according to your description, he's going to have to either change his approach or accept that he's the cause for delays (which his employees then cannot be blamed for). Refusing to change your approach, ignoring the problems you're creating, and pushing the blame onto others are no way of running a business.

– Flater
May 17 at 13:14

1

He does agree that he is the bottleneck and he most certainly does not blame others for it. But yes, I was looking for any tips that might not be readily obvious that could possibly reduce our bottleneck. Thanks for the insight

– user6567423
May 17 at 18:23

@user6567423 I'm curious if he has ever explained why he's the only one who can merge to trunk.

– Matthew
May 18 at 2:05

Not the answer I was looking for because I doubt my boss is going to loosen his grip on the trunk repository. But an incredibly helpful answer none-the-less, thanks for the insight!

– user6567423
May 16 at 19:34

@user6567423: If your boss becomes the bottleneck, which he now is according to your description, he's going to have to either change his approach or accept that he's the cause for delays (which his employees then cannot be blamed for). Refusing to change your approach, ignoring the problems you're creating, and pushing the blame onto others are no way of running a business.

– Flater
May 17 at 13:14

He does agree that he is the bottleneck and he most certainly does not blame others for it. But yes, I was looking for any tips that might not be readily obvious that could possibly reduce our bottleneck. Thanks for the insight

– user6567423
May 17 at 18:23

@user6567423 I'm curious if he has ever explained why he's the only one who can merge to trunk.

– Matthew
May 18 at 2:05

add a comment
|

answered May 16 at 20:17

Karl Bielefeldt

124k34 gold badges229 silver badges427 bronze badges

Thanks I think the tips on combining branches and preventing conflicts will probably be our best course of action.

– user6567423
May 16 at 20:29

add a comment
|

answered May 16 at 20:17

Karl Bielefeldt

124k34 gold badges229 silver badges427 bronze badges

Thanks I think the tips on combining branches and preventing conflicts will probably be our best course of action.

– user6567423
May 16 at 20:29

add a comment
|

answered May 16 at 20:17

Karl Bielefeldt

124k34 gold badges229 silver badges427 bronze badges

answered May 16 at 20:17

Karl Bielefeldt

124k34 gold badges229 silver badges427 bronze badges

answered May 16 at 20:17

Karl Bielefeldt

124k34 gold badges229 silver badges427 bronze badges

answered May 16 at 20:17

Karl Bielefeldt

124k34 gold badges229 silver badges427 bronze badges

answered May 16 at 20:17

Karl Bielefeldt

124k34 gold badges229 silver badges427 bronze badges

Thanks I think the tips on combining branches and preventing conflicts will probably be our best course of action.

– user6567423
May 16 at 20:29

add a comment
|

Thanks I think the tips on combining branches and preventing conflicts will probably be our best course of action.

– user6567423
May 16 at 20:29

Thanks I think the tips on combining branches and preventing conflicts will probably be our best course of action.

– user6567423
May 16 at 20:29

add a comment
|

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 branches will be thrown back because of conflicts, etc.

In my humble there are some management antipatterns:

He/she is the single choke point constraining the velocity of the team. Your bus factor is 1. The theory of constraints say that you should put your effort in improving the slowest part of chain.

Your manager is making your feedback cycle slower and reducing the agility of your team. Can you release every week?

Merges complexity grow exponentially with the amount of code. It is better to make 10 merges with 100 lines than 1 of 1000 lines. That is just one of the reasons why you should do it ASAP

If you detect a failure in the trunk you will do it latter in time. Which of the several branches was the problematic one

Decissions should be made by those who have more knoledge about them. Who knows more in this case? I bet that the developers that made the code.

You can't fix a bug in production if your manager is on holydays.

You are redoing work and throwing back branches. This is a waste of time. The time it is waiting to reach production is also waste.

Recomendations:

Your manager needs to delegate responsability to the team. You need
to show that the team is mature, professional. Make clear that they
can trust in the team

Implement some review method. May be you need the aproval of two other team members.

May be using SVN is making it harder. Give Git a try and see if it helps you. Even more. If you use GitHub you can use the Pull Request mechanism so that a merge requires certain votes.

Read and share information about agile practices, continous integration and DevOps.

edited May 17 at 13:07

answered May 17 at 9:38

Borjab

9845 silver badges15 bronze badges

7

I've worked professionally with both SVN and git, and I'd say that SVN is definitely part of the problem: It forces a single-merge-back-commit policy on branches which is not present in git. In git, all merges are equal, in SVN, some are more equal than others. Also, the lack of local commits makes it much harder to experiment with SVN than with git, and the lack of a staging zone only adds to the inflexibility of SVN. There's a reason why Torvalds did not just use SVN instead of developing git...

– cmaster
May 17 at 12:49

Git is so much better than svn in my opinion for the reasons @cmaster laid out and more

– reggaeguitar
May 17 at 15:43

I agree git would probably solve some of our merging problems, and dear god would I love to have rebase available. But I don't think we're going to make the switch anytime soon :(

– user6567423
May 17 at 18:25

1

@user6567423, I did a consultation last year where I helped a small team transition from svn to Git and change their workflow over, including training them on Git and setting them up with GitLab community edition (which is open source) for code reviews and collaboration. They were very enthusiastic about it; it was a night and day difference. (Also it took only three days.)

– Wildcard
May 17 at 20:03

add a comment
|

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 branches will be thrown back because of conflicts, etc.

In my humble there are some management antipatterns:

He/she is the single choke point constraining the velocity of the team. Your bus factor is 1. The theory of constraints say that you should put your effort in improving the slowest part of chain.

Your manager is making your feedback cycle slower and reducing the agility of your team. Can you release every week?

Merges complexity grow exponentially with the amount of code. It is better to make 10 merges with 100 lines than 1 of 1000 lines. That is just one of the reasons why you should do it ASAP

If you detect a failure in the trunk you will do it latter in time. Which of the several branches was the problematic one

Decissions should be made by those who have more knoledge about them. Who knows more in this case? I bet that the developers that made the code.

You can't fix a bug in production if your manager is on holydays.

You are redoing work and throwing back branches. This is a waste of time. The time it is waiting to reach production is also waste.

Recomendations:

Your manager needs to delegate responsability to the team. You need
to show that the team is mature, professional. Make clear that they
can trust in the team

Implement some review method. May be you need the aproval of two other team members.

May be using SVN is making it harder. Give Git a try and see if it helps you. Even more. If you use GitHub you can use the Pull Request mechanism so that a merge requires certain votes.

Read and share information about agile practices, continous integration and DevOps.

edited May 17 at 13:07

answered May 17 at 9:38

Borjab

9845 silver badges15 bronze badges

7

I've worked professionally with both SVN and git, and I'd say that SVN is definitely part of the problem: It forces a single-merge-back-commit policy on branches which is not present in git. In git, all merges are equal, in SVN, some are more equal than others. Also, the lack of local commits makes it much harder to experiment with SVN than with git, and the lack of a staging zone only adds to the inflexibility of SVN. There's a reason why Torvalds did not just use SVN instead of developing git...

– cmaster
May 17 at 12:49

Git is so much better than svn in my opinion for the reasons @cmaster laid out and more

– reggaeguitar
May 17 at 15:43

I agree git would probably solve some of our merging problems, and dear god would I love to have rebase available. But I don't think we're going to make the switch anytime soon :(

– user6567423
May 17 at 18:25

1

@user6567423, I did a consultation last year where I helped a small team transition from svn to Git and change their workflow over, including training them on Git and setting them up with GitLab community edition (which is open source) for code reviews and collaboration. They were very enthusiastic about it; it was a night and day difference. (Also it took only three days.)

– Wildcard
May 17 at 20:03

add a comment
|

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 branches will be thrown back because of conflicts, etc.

In my humble there are some management antipatterns:

He/she is the single choke point constraining the velocity of the team. Your bus factor is 1. The theory of constraints say that you should put your effort in improving the slowest part of chain.

Your manager is making your feedback cycle slower and reducing the agility of your team. Can you release every week?

Merges complexity grow exponentially with the amount of code. It is better to make 10 merges with 100 lines than 1 of 1000 lines. That is just one of the reasons why you should do it ASAP

If you detect a failure in the trunk you will do it latter in time. Which of the several branches was the problematic one

Decissions should be made by those who have more knoledge about them. Who knows more in this case? I bet that the developers that made the code.

You can't fix a bug in production if your manager is on holydays.

You are redoing work and throwing back branches. This is a waste of time. The time it is waiting to reach production is also waste.

Recomendations:

Your manager needs to delegate responsability to the team. You need
to show that the team is mature, professional. Make clear that they
can trust in the team

Implement some review method. May be you need the aproval of two other team members.

May be using SVN is making it harder. Give Git a try and see if it helps you. Even more. If you use GitHub you can use the Pull Request mechanism so that a merge requires certain votes.

Read and share information about agile practices, continous integration and DevOps.

edited May 17 at 13:07

answered May 17 at 9:38

Borjab

9845 silver badges15 bronze badges

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 branches will be thrown back because of conflicts, etc.

In my humble there are some management antipatterns:

He/she is the single choke point constraining the velocity of the team. Your bus factor is 1. The theory of constraints say that you should put your effort in improving the slowest part of chain.

Your manager is making your feedback cycle slower and reducing the agility of your team. Can you release every week?

Merges complexity grow exponentially with the amount of code. It is better to make 10 merges with 100 lines than 1 of 1000 lines. That is just one of the reasons why you should do it ASAP

If you detect a failure in the trunk you will do it latter in time. Which of the several branches was the problematic one

Decissions should be made by those who have more knoledge about them. Who knows more in this case? I bet that the developers that made the code.

You can't fix a bug in production if your manager is on holydays.

You are redoing work and throwing back branches. This is a waste of time. The time it is waiting to reach production is also waste.

Recomendations:

Your manager needs to delegate responsability to the team. You need
to show that the team is mature, professional. Make clear that they
can trust in the team

Implement some review method. May be you need the aproval of two other team members.

May be using SVN is making it harder. Give Git a try and see if it helps you. Even more. If you use GitHub you can use the Pull Request mechanism so that a merge requires certain votes.

Read and share information about agile practices, continous integration and DevOps.

edited May 17 at 13:07

answered May 17 at 9:38

Borjab

9845 silver badges15 bronze badges

edited May 17 at 13:07

answered May 17 at 9:38

Borjab

9845 silver badges15 bronze badges

answered May 17 at 9:38

Borjab

9845 silver badges15 bronze badges

answered May 17 at 9:38

Borjab

9845 silver badges15 bronze badges

7

I've worked professionally with both SVN and git, and I'd say that SVN is definitely part of the problem: It forces a single-merge-back-commit policy on branches which is not present in git. In git, all merges are equal, in SVN, some are more equal than others. Also, the lack of local commits makes it much harder to experiment with SVN than with git, and the lack of a staging zone only adds to the inflexibility of SVN. There's a reason why Torvalds did not just use SVN instead of developing git...

– cmaster
May 17 at 12:49

Git is so much better than svn in my opinion for the reasons @cmaster laid out and more

– reggaeguitar
May 17 at 15:43

I agree git would probably solve some of our merging problems, and dear god would I love to have rebase available. But I don't think we're going to make the switch anytime soon :(

– user6567423
May 17 at 18:25

1

@user6567423, I did a consultation last year where I helped a small team transition from svn to Git and change their workflow over, including training them on Git and setting them up with GitLab community edition (which is open source) for code reviews and collaboration. They were very enthusiastic about it; it was a night and day difference. (Also it took only three days.)

– Wildcard
May 17 at 20:03

add a comment
|

7

I've worked professionally with both SVN and git, and I'd say that SVN is definitely part of the problem: It forces a single-merge-back-commit policy on branches which is not present in git. In git, all merges are equal, in SVN, some are more equal than others. Also, the lack of local commits makes it much harder to experiment with SVN than with git, and the lack of a staging zone only adds to the inflexibility of SVN. There's a reason why Torvalds did not just use SVN instead of developing git...

– cmaster
May 17 at 12:49

Git is so much better than svn in my opinion for the reasons @cmaster laid out and more

– reggaeguitar
May 17 at 15:43

I agree git would probably solve some of our merging problems, and dear god would I love to have rebase available. But I don't think we're going to make the switch anytime soon :(

– user6567423
May 17 at 18:25

1

@user6567423, I did a consultation last year where I helped a small team transition from svn to Git and change their workflow over, including training them on Git and setting them up with GitLab community edition (which is open source) for code reviews and collaboration. They were very enthusiastic about it; it was a night and day difference. (Also it took only three days.)

– Wildcard
May 17 at 20:03

I've worked professionally with both SVN and git, and I'd say that SVN is definitely part of the problem: It forces a single-merge-back-commit policy on branches which is not present in git. In git, all merges are equal, in SVN, some are more equal than others. Also, the lack of local commits makes it much harder to experiment with SVN than with git, and the lack of a staging zone only adds to the inflexibility of SVN. There's a reason why Torvalds did not just use SVN instead of developing git...

– cmaster
May 17 at 12:49

Git is so much better than svn in my opinion for the reasons @cmaster laid out and more

– reggaeguitar
May 17 at 15:43

I agree git would probably solve some of our merging problems, and dear god would I love to have rebase available. But I don't think we're going to make the switch anytime soon :(

– user6567423
May 17 at 18:25

@user6567423, I did a consultation last year where I helped a small team transition from svn to Git and change their workflow over, including training them on Git and setting them up with GitLab community edition (which is open source) for code reviews and collaboration. They were very enthusiastic about it; it was a night and day difference. (Also it took only three days.)

– Wildcard
May 17 at 20:03

add a comment
|

answered May 17 at 0:28

bmm6o

1291 bronze badge

add a comment
|

answered May 17 at 0:28

bmm6o

1291 bronze badge

add a comment
|

answered May 17 at 0:28

bmm6o

1291 bronze badge

answered May 17 at 0:28

bmm6o

1291 bronze badge

answered May 17 at 0:28

bmm6o

1291 bronze badge

answered May 17 at 0:28

bmm6o

1291 bronze badge

answered May 17 at 0:28

bmm6o

1291 bronze badge

add a comment
|

Exercise for the reader: Write a program that prints my complete post :-)

This is madness. You will be spending an incredible amount of time merging.

answered May 16 at 19:36

gnasher729

22.9k2 gold badges34 silver badges69 bronze badges

Well not necessarily, unless the branches are in conflict then he can just merge them all into trunk seamlessly. We will usually try to prevent any conflicts by doing a test merge before we submit the branch for review but the conflicts come up inevitably as the number of branches in the queue increases. I do agree that it sounds like madness though.

– user6567423
May 16 at 19:38

2

Normal SVN merging behavior, as far as I can tell...

– cmaster
May 17 at 12:51

add a comment
|

Exercise for the reader: Write a program that prints my complete post :-)

This is madness. You will be spending an incredible amount of time merging.

answered May 16 at 19:36

gnasher729

22.9k2 gold badges34 silver badges69 bronze badges

Well not necessarily, unless the branches are in conflict then he can just merge them all into trunk seamlessly. We will usually try to prevent any conflicts by doing a test merge before we submit the branch for review but the conflicts come up inevitably as the number of branches in the queue increases. I do agree that it sounds like madness though.

– user6567423
May 16 at 19:38

2

Normal SVN merging behavior, as far as I can tell...

– cmaster
May 17 at 12:51

add a comment
|

Exercise for the reader: Write a program that prints my complete post :-)

This is madness. You will be spending an incredible amount of time merging.

answered May 16 at 19:36

gnasher729

22.9k2 gold badges34 silver badges69 bronze badges

Exercise for the reader: Write a program that prints my complete post :-)

This is madness. You will be spending an incredible amount of time merging.

answered May 16 at 19:36

gnasher729

22.9k2 gold badges34 silver badges69 bronze badges

answered May 16 at 19:36

gnasher729

22.9k2 gold badges34 silver badges69 bronze badges

answered May 16 at 19:36

gnasher729

22.9k2 gold badges34 silver badges69 bronze badges

answered May 16 at 19:36

gnasher729

22.9k2 gold badges34 silver badges69 bronze badges

Well not necessarily, unless the branches are in conflict then he can just merge them all into trunk seamlessly. We will usually try to prevent any conflicts by doing a test merge before we submit the branch for review but the conflicts come up inevitably as the number of branches in the queue increases. I do agree that it sounds like madness though.

– user6567423
May 16 at 19:38

2

Normal SVN merging behavior, as far as I can tell...

– cmaster
May 17 at 12:51

add a comment
|

Well not necessarily, unless the branches are in conflict then he can just merge them all into trunk seamlessly. We will usually try to prevent any conflicts by doing a test merge before we submit the branch for review but the conflicts come up inevitably as the number of branches in the queue increases. I do agree that it sounds like madness though.

– user6567423
May 16 at 19:38

2

Normal SVN merging behavior, as far as I can tell...

– cmaster
May 17 at 12:51

Well not necessarily, unless the branches are in conflict then he can just merge them all into trunk seamlessly. We will usually try to prevent any conflicts by doing a test merge before we submit the branch for review but the conflicts come up inevitably as the number of branches in the queue increases. I do agree that it sounds like madness though.

– user6567423
May 16 at 19:38

Normal SVN merging behavior, as far as I can tell...

– cmaster
May 17 at 12:51

add a comment
|

edited May 17 at 18:00

answered May 17 at 5:12

Martin Maat

9,9843 gold badges14 silver badges40 bronze badges

1

And how are you going to handle the release if just 1 of those features has a bug or isn't finished in time? "Branching itself is something you do not want to do unless you have a very good reason to do" -- Once you have 5 people working on multiple features each, you have to use branching unless you have a very very good reason not to.

– Ivo van der Veeken
May 17 at 12:53

It was about two thing: boss wants to remain the one and only gate keeper and things are not supposed to diverge too much. Yes, there will be a moment at which something was pushed that is yet to be scrutinized by boss. He should be able to do that quickly though and in the unlikely event he needs to deliver immediately he can revert the latest commits. This will keep things in sync and if you fail at anything you will certainly fail fast. Looks like a good compromise to me for the situation at hand.

– Martin Maat
May 17 at 13:23

1

I would consider this as a last resort

– reggaeguitar
May 17 at 15:45

add a comment
|

edited May 17 at 18:00

answered May 17 at 5:12

Martin Maat

9,9843 gold badges14 silver badges40 bronze badges

1

And how are you going to handle the release if just 1 of those features has a bug or isn't finished in time? "Branching itself is something you do not want to do unless you have a very good reason to do" -- Once you have 5 people working on multiple features each, you have to use branching unless you have a very very good reason not to.

– Ivo van der Veeken
May 17 at 12:53

It was about two thing: boss wants to remain the one and only gate keeper and things are not supposed to diverge too much. Yes, there will be a moment at which something was pushed that is yet to be scrutinized by boss. He should be able to do that quickly though and in the unlikely event he needs to deliver immediately he can revert the latest commits. This will keep things in sync and if you fail at anything you will certainly fail fast. Looks like a good compromise to me for the situation at hand.

– Martin Maat
May 17 at 13:23

1

I would consider this as a last resort

– reggaeguitar
May 17 at 15:45

add a comment
|

edited May 17 at 18:00

answered May 17 at 5:12

Martin Maat

9,9843 gold badges14 silver badges40 bronze badges

edited May 17 at 18:00

answered May 17 at 5:12

Martin Maat

9,9843 gold badges14 silver badges40 bronze badges

edited May 17 at 18:00

answered May 17 at 5:12

Martin Maat

9,9843 gold badges14 silver badges40 bronze badges

answered May 17 at 5:12

Martin Maat

9,9843 gold badges14 silver badges40 bronze badges

answered May 17 at 5:12

Martin Maat

9,9843 gold badges14 silver badges40 bronze badges

1

And how are you going to handle the release if just 1 of those features has a bug or isn't finished in time? "Branching itself is something you do not want to do unless you have a very good reason to do" -- Once you have 5 people working on multiple features each, you have to use branching unless you have a very very good reason not to.

– Ivo van der Veeken
May 17 at 12:53

It was about two thing: boss wants to remain the one and only gate keeper and things are not supposed to diverge too much. Yes, there will be a moment at which something was pushed that is yet to be scrutinized by boss. He should be able to do that quickly though and in the unlikely event he needs to deliver immediately he can revert the latest commits. This will keep things in sync and if you fail at anything you will certainly fail fast. Looks like a good compromise to me for the situation at hand.

– Martin Maat
May 17 at 13:23

1

I would consider this as a last resort

– reggaeguitar
May 17 at 15:45

add a comment
|

1

And how are you going to handle the release if just 1 of those features has a bug or isn't finished in time? "Branching itself is something you do not want to do unless you have a very good reason to do" -- Once you have 5 people working on multiple features each, you have to use branching unless you have a very very good reason not to.

– Ivo van der Veeken
May 17 at 12:53

It was about two thing: boss wants to remain the one and only gate keeper and things are not supposed to diverge too much. Yes, there will be a moment at which something was pushed that is yet to be scrutinized by boss. He should be able to do that quickly though and in the unlikely event he needs to deliver immediately he can revert the latest commits. This will keep things in sync and if you fail at anything you will certainly fail fast. Looks like a good compromise to me for the situation at hand.

– Martin Maat
May 17 at 13:23

1

I would consider this as a last resort

– reggaeguitar
May 17 at 15:45

And how are you going to handle the release if just 1 of those features has a bug or isn't finished in time? "Branching itself is something you do not want to do unless you have a very good reason to do" -- Once you have 5 people working on multiple features each, you have to use branching unless you have a very very good reason not to.

– Ivo van der Veeken
May 17 at 12:53

It was about two thing: boss wants to remain the one and only gate keeper and things are not supposed to diverge too much. Yes, there will be a moment at which something was pushed that is yet to be scrutinized by boss. He should be able to do that quickly though and in the unlikely event he needs to deliver immediately he can revert the latest commits. This will keep things in sync and if you fail at anything you will certainly fail fast. Looks like a good compromise to me for the situation at hand.

– Martin Maat
May 17 at 13:23

I would consider this as a last resort

– reggaeguitar
May 17 at 15:45

add a comment
|

draft saved

draft discarded

Thanks for contributing an answer to Software Engineering Stack Exchange!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Bsrgvty

7 Answers
7

Your Answer

Post as a guest

7 Answers
7

7 Answers
7

Post as a guest

Popular posts from this blog

Tamil (spriik) Luke uk diar | Nawigatjuun

7 Answers 7

Your Answer

Sign up or log in

Post as a guest

Post as a guest

7 Answers 7

7 Answers 7

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Popular posts from this blog

Tamil (spriik) Luke uk diar | Nawigatjuun

7 Answers
7

7 Answers
7

7 Answers
7