You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by C M <cm...@gmail.com> on 2013/09/23 19:44:22 UTC
Shared branch vs single branch
What are some of the pros/cons of using a single/shared branch versus the
private developer branch?
We are having an internal debate within the team where the idea of a
single/shared branch was proposed in reaction to two specific issues:
1. In the merge to trunk from individual developer branches, some code was
lost. It remains unclear whether it was user error on part of the person
doing the merge or the tool which caused the problem. In at least one case,
a file was partially merged.
2. The combined functionality (features assigned to two different
developers) was not included in the final application build and delivery.
In this case, the assignments were made months apart and one feature was
delivered without the other.
The expectation is that a shared/single branch will correct these issues. I
am curious to know what advice others can offer and what (if any) potential
issues we may experience with the new paradigm.
Thanks.
Amad.
Re: Shared branch vs single branch
Posted by Branko Čibej <br...@wandisco.com>.
On 23.09.2013 19:44, C M wrote:
> What are some of the pros/cons of using a single/shared branch versus
> the private developer branch?
>
> We are having an internal debate within the team where the idea of a
> single/shared branch was proposed in reaction to two specific issues:
>
> 1. In the merge to trunk from individual developer branches, some code
> was lost. It remains unclear whether it was user error on part of the
> person doing the merge or the tool which caused the problem. In at
> least one case, a file was partially merged.
>
> 2. The combined functionality (features assigned to two different
> developers) was not included in the final application build and
> delivery. In this case, the assignments were made months apart and one
> feature was delivered without the other.
>
> The expectation is that a shared/single branch will correct these
> issues. I am curious to know what advice others can offer and what (if
> any) potential issues we may experience with the new paradigm.
Changing the way you do branching will not solve your problems, since
the they're by tool but by lack of communication within the team, and
non-existent product management. User error will always happen, but
Subversion will not magically warn you about it. You need other quality
assurance procedures in place for that.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Shared branch vs single branch
Posted by Edwin Castro <0p...@gmx.us>.
On 9/23/13 1:45 PM, Les Mikesell wrote:
>> "Trunk is dirty" won't save you from bad merges, it'll just make more
>> > conflicts in your working copy as you do updates - something that drove a
>> > colleague of mine nuts so I started working in my own branch for that
>> > project. You also have to more frequently be doing "svn update" on your
>> > working copy to minimize impacts of what others are doing.
> Just a matter of whether you want to resolve small conflicts as they
> happen with frequent updates/commits (and maybe take advantages of
> other's changes sooner rather than later), or do you want to complete
> the changes in isolation so you can prove that your version was the
> best and should win if there is a conflict?
The isolation provided by branches can result in code that diverges
greatly because the child branch is not kept in sync with its parent.
Large time periods of isolation can cause some very hairy merges.
Re: Shared branch vs single branch
Posted by Les Mikesell <le...@gmail.com>.
On Mon, Sep 23, 2013 at 3:15 PM, BRM <bm...@yahoo.com> wrote:
> If by "single/shared" branch you mean everyone working out of the same
> place...then yes - you'll trip over each other from time to time.
Conflicts are going to happen. The question is more about the timing
- and how your team works (or fights...) together.
> I've worked in both "trunk is prestine" (all work in branches) and "trunk is
> dirty" (all work in trunk) models; when you have multiple people the "trunk
> is prestine" works a lot better, but as others have noted people doing the
> merges have to ensure they are done right - and that includes testing.
If you use 'trunk is dirty', you will also want 'release' branches so
a broken trunk as you make big changes is not a serious problem.
> "Trunk is dirty" won't save you from bad merges, it'll just make more
> conflicts in your working copy as you do updates - something that drove a
> colleague of mine nuts so I started working in my own branch for that
> project. You also have to more frequently be doing "svn update" on your
> working copy to minimize impacts of what others are doing.
Just a matter of whether you want to resolve small conflicts as they
happen with frequent updates/commits (and maybe take advantages of
other's changes sooner rather than later), or do you want to complete
the changes in isolation so you can prove that your version was the
best and should win if there is a conflict?
--
Les Mikesell
lesmikesell@gmail.com
Re: Shared branch vs single branch
Posted by Edwin Castro <0p...@gmx.us>.
On 9/23/13 1:15 PM, BRM wrote:
> "Trunk is dirty" won't save you from bad merges, it'll just make more
> conflicts in your working copy as you do updates - something that
> drove a colleague of mine nuts so I started working in my own branch
> for that project. You also have to more frequently be doing "svn
> update" on your working copy to minimize impacts of what others are doing.
In my experience, working in a dirty trunk typically results in less
checkins by developers. I don't consider this a good thing as their
changes tend to remain uncommitted for very large periods of time (in
the order of a week or so).
Re: Shared branch vs single branch
Posted by BRM <bm...@yahoo.com>.
If by "single/shared" branch you mean everyone working out of the same place...then yes - you'll trip over each other from time to time.
I've worked in both "trunk is prestine" (all work in branches) and "trunk is dirty" (all work in trunk) models; when you have multiple people the "trunk is prestine" works a lot better, but as others have noted people doing the merges have to ensure they are done right - and that includes testing.
"Trunk is dirty" won't save you from bad merges, it'll just make more conflicts in your working copy as you do updates - something that drove a colleague of mine nuts so I started working in my own branch for that project. You also have to more frequently be doing "svn update" on your working copy to minimize impacts of what others are doing.
$0.02
Ben
________________________________
From: C M <cm...@gmail.com>
To: Les Mikesell <le...@gmail.com>
Cc: Bob Archer <Bo...@amsi.com>; Subversion <us...@subversion.apache.org>
Sent: Monday, September 23, 2013 4:04 PM
Subject: Re: Shared branch vs single branch
Unfortunately, we are lacking on processes and there's a definite lack of product management.
But coming back to my original question: Are there any potential gotchas with using a single/shared branch? For now, that's the only change the team (and leadership) is looking to as the "solution".
Our developers code on a Unix like platform and have little SVN experience to boot. The idea of turning over merging to them seems to be a recipe for disaster. I would prefer to let the CM team handle the merges and figure out what I did incorrectly to mess up the previous merges.
On Mon, Sep 23, 2013 at 2:42 PM, Les Mikesell <le...@gmail.com> wrote:
On Mon, Sep 23, 2013 at 2:35 PM, Bob Archer <Bo...@amsi.com> wrote:
>>> On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer <Bo...@amsi.com> wrote:
>>> >> It really depends. I think all work for a specific release should be done in a
>>> single branch/folder. Many people follow the stable trunk model. In this model
>>> you generally do all work on trunk and then branch for a release. This is the
>>> same model svn itself is developed under. In this model you would also use
>>> what are called "feature" branches. This is generally for a feature/use case that
>>> will take more than a day to complete or will be worked on by more than one
>>> developer.
>>> >
>>> > Once again, it's up to the people not the tool to ensure your release
>>> management is done properly.
>>>
>>> Well, sort-of. It is always a good idea to (a) include tests for new
>>> code and (b) have a workflow that ensures that the tests are run and
>>> that someone checks the results. Expecting one person to never make
>>> a mistake just doesn't always work out.
>>
>> Isn't is up to the people to put those processes in place? To create the correct workflow? To write the automation?
>>
>> I don't think I ever said it should be ONE person's responsibility to manually do this work. Where did I say that?
>
>You didn't explicitly say it was one person's fault, but what you said
>could easily be interpreted that way by anyone who had to ask the
>question in the first place.... Yes, people have to set things up,
>but there are tools that can help.
>
>--
> Les Mikesell
> lesmikesell@gmail.com
>
RE: Shared branch vs single branch
Posted by Andrew Reedick <An...@cbeyond.net>.
> From: C M [mailto:cmanalyst66@gmail.com]
> Sent: Monday, September 23, 2013 4:05 PM
> To: Les Mikesell
> Cc: Bob Archer; Subversion
> Subject: Re: Shared branch vs single branch
>
> Unfortunately, we are lacking on processes and there's a definite lack of product management.
> But coming back to my original question: Are there any potential gotchas with using a single/shared branch? For now, that's the only change the team (and leadership) is looking to as the "solution".
Firstly, one branch only works if you only ever have one and only one development steam going at a time. This "never" happens because at a minimum, you need a branch to support production fixes, a branch for QA fixes for the "final" release candidate, and a branch for the next release, e.g.:
* /branches/1.0.1 - prod bug fixes for 1.0.0 in prod
* /branchs/1.1.0 - 1.1.0 is in its final round of QA testing, so only 1.1.0 bug fix work is accepted
* /branches/trunk (aka 2.0 work)
In other words, don't ignore, gloss over, or otherwise lie to yourselves over the need to support multiple branches and merging.
Secondly, everyone will still require training. Multiple branches (see Firstly above) will require training for everyone. Even if you have the CM guy do the merges, you still need to teach the developers how to avoid creating Evil Twins (i.e. a particular Tree Conflict.) An Evil Twin is created when you 'svn add foo.java' on both the trunk and on the branch, instead of merging 'foo.java' from trunk to the branch.
Thirdly, you need process and project management. If you can't track your work, even "single" branching is going to fail hard, such as when you have to back a feature out of trunk due to time constraints. If you can't identify/track the work back to individual check-ins, then you will have great difficulty in reverse merging a feature out of trunk and merging it to its own branch. If you can't assign work and/or manage requirements, then, technically, you cannot, in good faith, decide whether single or multiple branches are right for you.
Fourthly, Semper Gumby; "Always Flexible." Branching gives you flexibility. Going with single branching limits your ability to change, adapt to, or manage releases. If you have lousy requirements management, then single branching means you're more likely to wind up in death marches, late nights, and relying on full regression testing (which takes time that you won't have) to verify that you all haven't broken something stupid on trunk. If I had lousy/incomplete/late requirements then I would want to use feature branches to help mitigate the pain.
Fifthly, keep your resume up to date. A good marriage counselor helps as well. Keep in contact with your company recruiter in case you experience higher than average developer burn out. Over-dramatic, but no process == inefficient work == making up the time with people's personal time, i.e. late hours, weekend work, etc..
To actually answer your question, the pitfalls of single branching are:
a) people working on the same files will create conflicts during 'svn update'. However, svn locking can help reduce the pain. Dividing up the work so that folks are working on different parts of the software helps as well. Communication is key when multiple developers touch the same set of files.
b) having to remove code. If a feature is unstable or cannot be completed in time, then you will need to reverse merge it out. Which can be more difficult with single branching over feature branching. Difficultly is increased the longer/bigger the release is, due to the increased chance of interdependencies with the removed feature.
However, if you're doing Agile development (short release cycles/sprints, a small set of well defined requirements for each sprint, etc.) then the dirty trunk approach should work mostly easily. However, the longer your release cycle, the greater your chances of having to rip out a feature and the greater the difficulty it will be in doing so (due to dependencies, larger set of QA test to run through, etc..)
> Our developers code on a Unix like platform and have little SVN experience to boot. The idea of turning over merging to them seems to be a recipe for disaster. I would prefer to let the CM team handle the merges and figure out what I did incorrectly to mess up the previous merges.
Go with the trained CM guy. Tree conflicts in Subversion aren't exactly well documented and require some experience to do correctly. However, your CM guy can't merge based on business logic, e.g. if something *shouldn't* be merged (such as a temporary hack) then you Someone(tm) needs to work with the Merge Meister, i.e. have a merge party.
Good luck. It doesn't have to be perfect, but the more up front planning you do, the less of your life you lose to stress. Also, defining a process is the first step towards process improvement and a saner career. =)
/soapbox off
Re: Shared branch vs single branch
Posted by Edwin Castro <0p...@gmx.us>.
On 9/23/13 1:04 PM, C M wrote:
> The idea of turning over merging to them seems to be a recipe for
> disaster.
IMHO, merges should be performed by the individual who is most
knowledgeable of the code being merged. When conflicts occur, and they
WILL occur, the individual performing the merge will need to make
decisions about how to resolve those conflicts. Sometimes the knowledge
required is tool usage (handling tree conflicts for example) but at
other times you need to understand what two diverging lines of code are
trying to do in order to make a correct choice.
Re: Shared branch vs single branch
Posted by Ben Reser <be...@reser.org>.
On 9/23/13 1:04 PM, C M wrote:
> But coming back to my original question: Are there any potential gotchas with
> using a single/shared branch? For now, that's the only change the team (and
> leadership) is looking to as the "solution".
In my opinion there isn't a single answer to this question. Which strategy you
want to use is entirely situational.
If you're using a single shared trunk then you're going to run into situations
where you'll want to still use a branch because the work being done is
disruptive. The only alternative to that is to start adding flags in your
build system to hide this.
If you use branches often, then you'll still have changes where they are small
enough there's no need for the branch.
> Our developers code on a Unix like platform and have little SVN experience to
> boot. The idea of turning over merging to them seems to be a recipe for
> disaster. I would prefer to let the CM team handle the merges and figure out
> what I did incorrectly to mess up the previous merges.
In truth every commit is a merge (the HTTP method SVN uses for commit is
MERGE). Who better to be committing/merging than your developers?
Consider the following situation. Developer A and B are both working on a
project we'll call widgets. The code has the following layout.
widgets
widget/foo.c
widget/bar.c
widget/baz.c
main.c
Developer A starts modifying a function we'll call stamp(), let's pretend that
stamp controls the formatting of a date and serial number coding on the widgets
we're producing and lives in main.c. foo and bar widgets have this coding but
the baz widget is new and hasn't had it added yet. Developer A has been given
the task of adding a time code to the stamp. Developer A has an entire working
copy at revision 20.
Developer B is working on the baz widget and is now getting to the point of
adding the stamp and adds a call to stamp() to baz.c. He commits revision 21
doing so.
Developer A continues working against revision 20 has finished adding time to
stamp() and in the process adding a new argument to input the time to stamp.
He updated the calls in foo.c and bar.c but since he only has r20 he doesn't
see that widget/baz.c has added such a call. He commits his code in r22.
Now the baz widget has been broken. Subversion didn't complain because the
changes were in different files and don't appear to conflict.
Now consider if both developers had been working on branches. If they merge
their branches back to trunk in the same order then you'll have the same problem.
All branches do is delay the conflict and potentially limit the number of
people that are impacted by the conflict. In my opinion the further you get
from the creation of the conflict both in time and individuals the harder it is
going to be to fix it. But that also doesn't mean you should never use branches.
I really don't understand how CM doing merges helps avoid problems. The
developers are in the best position to understand the impacts of their merges
and deal with any conflicts (raised by Subversion or semantic and not shown as
a conflict by Subversion).
If you're uncomfortable with your developers knowledge of Subversion, you
should invest in them and spend the time improving that knowledge. It'll pay
off more than any change in branch strategies ever can, since as I demonstrated
above, both strategies can have the identical problem.
Re: Shared branch vs single branch
Posted by C M <cm...@gmail.com>.
Unfortunately, we are lacking on processes and there's a definite lack of
product management.
But coming back to my original question: Are there any potential gotchas
with using a single/shared branch? For now, that's the only change the team
(and leadership) is looking to as the "solution".
Our developers code on a Unix like platform and have little SVN experience
to boot. The idea of turning over merging to them seems to be a recipe for
disaster. I would prefer to let the CM team handle the merges and figure
out what I did incorrectly to mess up the previous merges.
On Mon, Sep 23, 2013 at 2:42 PM, Les Mikesell <le...@gmail.com> wrote:
> On Mon, Sep 23, 2013 at 2:35 PM, Bob Archer <Bo...@amsi.com> wrote:
> >> On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer <Bo...@amsi.com>
> wrote:
> >> >> It really depends. I think all work for a specific release should be
> done in a
> >> single branch/folder. Many people follow the stable trunk model. In
> this model
> >> you generally do all work on trunk and then branch for a release. This
> is the
> >> same model svn itself is developed under. In this model you would also
> use
> >> what are called "feature" branches. This is generally for a feature/use
> case that
> >> will take more than a day to complete or will be worked on by more than
> one
> >> developer.
> >> >
> >> > Once again, it's up to the people not the tool to ensure your release
> >> management is done properly.
> >>
> >> Well, sort-of. It is always a good idea to (a) include tests for new
> >> code and (b) have a workflow that ensures that the tests are run and
> >> that someone checks the results. Expecting one person to never make
> >> a mistake just doesn't always work out.
> >
> > Isn't is up to the people to put those processes in place? To create the
> correct workflow? To write the automation?
> >
> > I don't think I ever said it should be ONE person's responsibility to
> manually do this work. Where did I say that?
>
> You didn't explicitly say it was one person's fault, but what you said
> could easily be interpreted that way by anyone who had to ask the
> question in the first place.... Yes, people have to set things up,
> but there are tools that can help.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
Re: Shared branch vs single branch
Posted by Les Mikesell <le...@gmail.com>.
On Mon, Sep 23, 2013 at 2:35 PM, Bob Archer <Bo...@amsi.com> wrote:
>> On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer <Bo...@amsi.com> wrote:
>> >> It really depends. I think all work for a specific release should be done in a
>> single branch/folder. Many people follow the stable trunk model. In this model
>> you generally do all work on trunk and then branch for a release. This is the
>> same model svn itself is developed under. In this model you would also use
>> what are called "feature" branches. This is generally for a feature/use case that
>> will take more than a day to complete or will be worked on by more than one
>> developer.
>> >
>> > Once again, it's up to the people not the tool to ensure your release
>> management is done properly.
>>
>> Well, sort-of. It is always a good idea to (a) include tests for new
>> code and (b) have a workflow that ensures that the tests are run and
>> that someone checks the results. Expecting one person to never make
>> a mistake just doesn't always work out.
>
> Isn't is up to the people to put those processes in place? To create the correct workflow? To write the automation?
>
> I don't think I ever said it should be ONE person's responsibility to manually do this work. Where did I say that?
You didn't explicitly say it was one person's fault, but what you said
could easily be interpreted that way by anyone who had to ask the
question in the first place.... Yes, people have to set things up,
but there are tools that can help.
--
Les Mikesell
lesmikesell@gmail.com
RE: Shared branch vs single branch
Posted by Bob Archer <Bo...@amsi.com>.
> On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer <Bo...@amsi.com> wrote:
> >> It really depends. I think all work for a specific release should be done in a
> single branch/folder. Many people follow the stable trunk model. In this model
> you generally do all work on trunk and then branch for a release. This is the
> same model svn itself is developed under. In this model you would also use
> what are called "feature" branches. This is generally for a feature/use case that
> will take more than a day to complete or will be worked on by more than one
> developer.
> >
> > Once again, it's up to the people not the tool to ensure your release
> management is done properly.
>
> Well, sort-of. It is always a good idea to (a) include tests for new
> code and (b) have a workflow that ensures that the tests are run and
> that someone checks the results. Expecting one person to never make
> a mistake just doesn't always work out.
Isn't is up to the people to put those processes in place? To create the correct workflow? To write the automation?
I don't think I ever said it should be ONE person's responsibility to manually do this work. Where did I say that?
BOb
>
> A general rule can't cover all cases, but in general I think the longer you let
> branches diverge with isolated work, the more likely they are to have
> conflicting changes that will take extra work to resolve when you finally do
> merge.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
Re: Shared branch vs single branch
Posted by Les Mikesell <le...@gmail.com>.
On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer <Bo...@amsi.com> wrote:
>> It really depends. I think all work for a specific release should be done in a single branch/folder. Many people follow the stable trunk model. In this model you generally do all work on trunk and then branch for a release. This is the same model svn itself is developed under. In this model you would also use what are called "feature" branches. This is generally for a feature/use case that will take more than a day to complete or will be worked on by more than one developer.
>
> Once again, it's up to the people not the tool to ensure your release management is done properly.
Well, sort-of. It is always a good idea to (a) include tests for new
code and (b) have a workflow that ensures that the tests are run and
that someone checks the results. Expecting one person to never make
a mistake just doesn't always work out.
A general rule can't cover all cases, but in general I think the
longer you let branches diverge with isolated work, the more likely
they are to have conflicting changes that will take extra work to
resolve when you finally do merge.
--
Les Mikesell
lesmikesell@gmail.com
RE: Shared branch vs single branch
Posted by Bob Archer <Bo...@amsi.com>.
> What are some of the pros/cons of using a single/shared branch versus the
> private developer branch?
> We are having an internal debate within the team where the idea of a
> single/shared branch was proposed in reaction to two specific issues:
> 1. In the merge to trunk from individual developer branches, some code was
> lost. It remains unclear whether it was user error on part of the person doing
> the merge or the tool which caused the problem. In at least one case, a file was
> partially merged.
It was the user that did the merge. It will only commit what you tell it to commit. This is a people problem, not a branch strategy issue.
> 2. The combined functionality (features assigned to two different developers)
> was not included in the final application build and delivery. In this case, the
> assignments were made months apart and one feature was delivered without
> the other.
Once again, a people problem.
> The expectation is that a shared/single branch will correct these issues. I am
> curious to know what advice others can offer and what (if any) potential issues
> we may experience with the new paradigm.
> Thanks.
> Amad.
It really depends. I think all work for a specific release should be done in a single branch/folder. Many people follow the stable trunk model. In this model you generally do all work on trunk and then branch for a release. This is the same model svn itself is developed under. In this model you would also use what are called "feature" branches. This is generally for a feature/use case that will take more than a day to complete or will be worked on by more than one developer.
Once again, it's up to the people not the tool to ensure your release management is done properly.
BOb