Discuss: Branching Strategy and SCM

[Om <bi...@gmail.com>]

On Mon, Aug 13, 2012 at 5:50 PM, Justin Mclean <ju...@classsoftware.com>wrote:

> Hi,
>
> - Unsure how it is decided what from develop/trunk goes into a release.
> IMO this will make releases a lot more work for the release manager and
> less likely someone will want to take on that role.
>

Doesn't option 4 exacerbate this problem?  How can this be a reason to vote
'for' option 4?

Re: Discuss: Branching Strategy and SCM

[Omar Gonzalez <om...@gmail.com>]

On Tue, Aug 14, 2012 at 7:58 AM, Greg Reddin <gr...@gmail.com> wrote:

> On Tue, Aug 14, 2012 at 9:53 AM, Omar Gonzalez
> <om...@gmail.com> wrote:
> > It sounds like hell to me.
>
> I don't see the hell in it -- at least I don't see the hell that would
> be avoided under a distributed SCM. How would that use case play out
> in git?
>


This is how it would play out in Git.

1. Greg: git branch maven-support from the dev branch, creating a Maven
Support feature branch
2. Alex: git branch UIComponent-refactor from the dev branch, creating a
UIComponent refactor feature branch
3. Over the course of two or three weeks people commit to both of these
branches. People also commit to trunk.
4. Om decides to make a release from dev branch. A release branch is
created: git branch release-v.1.1.4
5. Updates are made to release to prepare the new version.
6. Om is done preparing the release so he: git checkout dev to go back to
dev branch.
7. Om runs: git merge release-v.1.1.4 on the master branch, triggering a
Jenkins build and deploy of a new production version
8. Om runs: git merge release-v.1.1.4 on the dev branch to catch up the
Flex.Next branch
9. The release branch is tagged "v.1.1.4" and then the release branch can
be deleted
10. Greg and Alex continue to work and not worry about what is happening in
dev or master.
11. Alex completes his work first because he's much faster than Greg :-)
12. After some discussion on flex-dev everybody agrees Alex's work is worth
integrating.
13. Alex does a git rebase. This takes Alex's current changes and puts them
in a git stash. Git pulls all the latest changes to the trunk since the
point that the branch was created, including latest release, etc. Rebase
reapplies all the changes that were pulled from the dev branch as well as
Alex's changes, in chronological order. This makes merging a lot easier
because you are merging smaller chunks of much more digestable code as
opposed to a huge merge or syncing over and over (disrupting actual
development of the feature).
14. Once the rebase is complete Alex goes to dev branch (git checkout dev)
and runs: git merge my-feature-branch
15. Alex is done merging his new feature to dev branch (flex.next).
16. Greg does the same process whenever his feature is ready, not having to
constantly merge to make sure he doesn't diverge too much.
17. Alex makes a release from dev the same as Om.
18. Greg continues working not caring what goes on in dev.
19. Eventually Greg & team *finally* finish their work.
20. After discussion on flex-dev everybody agrees that Greg's work is
indispensable and needs to be integrated.
21. Greg does the same as step 10. Easily reapplies all changes to the dev
branch since his original creation of the branch.
22. Greg does a git merge gregs-feature-branch
23. Greg is done integrating his work to dev.
24. Greg makes a release from dev following same steps Om did in step 9.


The main differences are that you don't have to continuously stop your
development in a feature branch to merge code that's been added to the
trunk or dev branches. Git rebase makes rebasing/resyncing your branch with
the latest features a lot nicer. This leads to less time spent in an SCM
program and more time developing Flex. Less time doing svn merge, more time
adding new features. And merging in Git is much easier, and to run into
"merge hell" you have to try really hard to do so.

Branching is different in that in SVN when you branch you copy all the
files of the repository into a new location inside the repository. When you
branch in Git you're not duplicating files to a new location within the
repository, the entire repository becomes a new branch. You view them by
typing "git branch" to see what branches are available, as opposed to
looking in a folder to see the thousands of files that have been put into
branches. When Git creates new branches it is only dealing in metadata that
logs what the new changes are. This not only makes the storage more
efficient and Git itself faster, but it makes managing merges more
efficient.

-omar

Re: Discuss: Branching Strategy and SCM

[Omar Gonzalez <om...@gmail.com>]

On Tuesday, August 14, 2012, Greg Reddin wrote:

> On Tue, Aug 14, 2012 at 9:53 AM, Omar Gonzalez
> <omarg.developer@gmail.com <javascript:;>> wrote:
> > It sounds like hell to me.
>
> I don't see the hell in it -- at least I don't see the hell that would
> be avoided under a distributed SCM. How would that use case play out
> in git?
>

I can elaborate on that in a bit I have an hour drive to an onsite client
today so I'll describe it in a few.

-omar

Re: Discuss: Branching Strategy and SCM

[Greg Reddin <gr...@gmail.com>]

On Tue, Aug 14, 2012 at 9:53 AM, Omar Gonzalez
<om...@gmail.com> wrote:
> It sounds like hell to me.

I don't see the hell in it -- at least I don't see the hell that would
be avoided under a distributed SCM. How would that use case play out
in git?

Re: Discuss: Branching Strategy and SCM

[Omar Gonzalez <om...@gmail.com>]

On Tuesday, August 14, 2012, Greg Reddin wrote:

> On Mon, Aug 13, 2012 at 10:29 PM, Omar Gonzalez
> <omarg.developer@gmail.com <javascript:;>> wrote:
> > The way I see it, if there are a bunch of developers working in trunk,
> and
> > they happen to leave things unfinished or unstable, then somebody has to
> go
> > through all of that and figure out what is actually ready for a release
> and
> > what is not. Without a well defined SVN strategy this is going to be a
> mess
> > that someone will have to clean up.
>
> Everyone is working in trunk. Some things are unstable. A discussion
> starts up on list that it's about time we cut a release. We either
> decide to: 1) move some stuff from trunk to a branch so we can make a
> release from trunk, or 2) cut a branch from trunk and make a release
> from the branch. Either way we spend some time either getting trunk
> stable for a release or getting a branch stable for a release. Then we
> make a release and work goes on.
>
> Personally, I wouldn't commit any unstable code to trunk. If I'm
> working on something that's going to span more than one or two
> commits, I'd do it in a feature branch. When the feature branch is
> done I merge to trunk.
>
> Here's a use case: Greg wants to implement better Maven support and
> Alex wants to refactor UIComponent at the same time. Both of these are
> long-running efforts that touch a lot of code. Nobody knows how big
> either one really is or how long it will take. So here's a script of
> how it might play out:
>
> 1. Greg: svn cp trunk branches/maven-support
> 2. Alex: svn cp trunk branches/UIComponent-refactor.
> 3. Over the course of two or three weeks people commit to both of
> these branches. People also commit to trunk.
> 4. Periodically Greg and Alex run svn merge trunk in their branches to
> keep the branches up to date with trunk.
> 5. Om decides to make a release from trunk, so all effort in trunk
> goes toward making the release. Work continues in the two branches.
> 6. Release is cut from trunk and a tag is created.
> 7. Greg and Alex continue to run svn merge trunk to keep their
> branches up to date.
> 8. Alex completes his work first because he's much faster than Greg :-)
> 9. After some discussion on flex-dev everybody agrees Alex's work is
> worth integrating.
> 10. Alex does a final svn merge trunk in his branch to get the latest
> updates.
> 11. Alex goes to trunk and runs svn merge --reintegrate
> branches/UIComponent-refactor,
> 12. Alex makes a commit to trunk.
> 13. Greg does another svn merge trunk in his branch to get the
> UIComponent refactor.
> 14. Alex makes a release from trunk.
> 15. Greg repeats step 13.
> 16. Eventually Greg & team *finally* finish their work.
> 17. After discussion on flex-dev everybody agrees that Greg's work is
> indispensable and needs to be integrated.
> 18. Greg does a final svn merge trunk in the maven branch to bring
> over latest changes.
> 19. Greg does a svn merge --reintegrate branches/maven-support in trunk.
> 20. Greg makes a commit to trunk.
> 21. Greg makes a release from trunk.
> ...
>
> Notice a few things:
> * Potential pain points come in step 7 because the released code might
> be hard to integrate into the branches, and particularly steps 9 - 12
> and 16 - 20 because we're reintegrating significant changes back into
> the codebase. However these pain points are at isolated, atomic stages
> along the way.
> * Notice the discussion that takes place at step 5, step 9, and step
> 12. When we are ready to make a release we talk about it. Everybody
> works together to make it happen. When we are ready to integrate
> significant progress we talk about it and everybody works together to
> make it happen.
>
> It's not perfect. It's not necessarily fast. But it's proven to work
> for a lot of apache projects and it doesn't get much simpler.
>
> Greg
>

It sounds like hell to me.

-omar

Re: Discuss: Branching Strategy and SCM

[Greg Reddin <gr...@gmail.com>]

On Mon, Aug 13, 2012 at 10:29 PM, Omar Gonzalez
<om...@gmail.com> wrote:
> The way I see it, if there are a bunch of developers working in trunk, and
> they happen to leave things unfinished or unstable, then somebody has to go
> through all of that and figure out what is actually ready for a release and
> what is not. Without a well defined SVN strategy this is going to be a mess
> that someone will have to clean up.

Everyone is working in trunk. Some things are unstable. A discussion
starts up on list that it's about time we cut a release. We either
decide to: 1) move some stuff from trunk to a branch so we can make a
release from trunk, or 2) cut a branch from trunk and make a release
from the branch. Either way we spend some time either getting trunk
stable for a release or getting a branch stable for a release. Then we
make a release and work goes on.

Personally, I wouldn't commit any unstable code to trunk. If I'm
working on something that's going to span more than one or two
commits, I'd do it in a feature branch. When the feature branch is
done I merge to trunk.

Here's a use case: Greg wants to implement better Maven support and
Alex wants to refactor UIComponent at the same time. Both of these are
long-running efforts that touch a lot of code. Nobody knows how big
either one really is or how long it will take. So here's a script of
how it might play out:

1. Greg: svn cp trunk branches/maven-support
2. Alex: svn cp trunk branches/UIComponent-refactor.
3. Over the course of two or three weeks people commit to both of
these branches. People also commit to trunk.
4. Periodically Greg and Alex run svn merge trunk in their branches to
keep the branches up to date with trunk.
5. Om decides to make a release from trunk, so all effort in trunk
goes toward making the release. Work continues in the two branches.
6. Release is cut from trunk and a tag is created.
7. Greg and Alex continue to run svn merge trunk to keep their
branches up to date.
8. Alex completes his work first because he's much faster than Greg :-)
9. After some discussion on flex-dev everybody agrees Alex's work is
worth integrating.
10. Alex does a final svn merge trunk in his branch to get the latest updates.
11. Alex goes to trunk and runs svn merge --reintegrate
branches/UIComponent-refactor,
12. Alex makes a commit to trunk.
13. Greg does another svn merge trunk in his branch to get the
UIComponent refactor.
14. Alex makes a release from trunk.
15. Greg repeats step 13.
16. Eventually Greg & team *finally* finish their work.
17. After discussion on flex-dev everybody agrees that Greg's work is
indispensable and needs to be integrated.
18. Greg does a final svn merge trunk in the maven branch to bring
over latest changes.
19. Greg does a svn merge --reintegrate branches/maven-support in trunk.
20. Greg makes a commit to trunk.
21. Greg makes a release from trunk.
...

Notice a few things:
* Potential pain points come in step 7 because the released code might
be hard to integrate into the branches, and particularly steps 9 - 12
and 16 - 20 because we're reintegrating significant changes back into
the codebase. However these pain points are at isolated, atomic stages
along the way.
* Notice the discussion that takes place at step 5, step 9, and step
12. When we are ready to make a release we talk about it. Everybody
works together to make it happen. When we are ready to integrate
significant progress we talk about it and everybody works together to
make it happen.

It's not perfect. It's not necessarily fast. But it's proven to work
for a lot of apache projects and it doesn't get much simpler.

Greg

Re: Discuss: Branching Strategy and SCM

[João Fernandes <jo...@gmail.com>]

On 14 August 2012 20:37, Om <bi...@gmail.com> wrote:

> > > Alex but couldn't we simply make "[VOTE]/[DISCUSS] - [MERGE]" mandatory
> > > once we want to merge something to Develop branch?
> > >
> > > João Fernandes
> > Yes, but in order to vote, I have to get your branch and build it and
> test
> > it in order to vote.  40 committers, 40 branches at minimum.  I'd be
> > interested in hearing from the mentors how they "promote" stuff from
> branch
> > to trunk.   I was hoping it would be easier:  Instead of a vote, you just
> > check it into "develop" and we veto if we don't like it.  Then fewer
> folks
> > have to go look at it.  But that means it might not be quite ready to go
> to
> > production and need to be filtered out before release if we can't get it
> to
> > production quality in time.
> >
> >
> It should be up to a committer to decide when a feature should go from a
> feature branch to develop.  We should be able to trust a committer's
> judgement for such things.  It will be up to the release manager +
> discussion on the mailing list to accept what is in develop to cut into a
> release branch.
>
> Om
>

ok thanks

-- 

João Fernandes

Re: Discuss: Branching Strategy and SCM

[Om <bi...@gmail.com>]

> > Alex but couldn't we simply make "[VOTE]/[DISCUSS] - [MERGE]" mandatory
> > once we want to merge something to Develop branch?
> >
> > João Fernandes
> Yes, but in order to vote, I have to get your branch and build it and test
> it in order to vote.  40 committers, 40 branches at minimum.  I'd be
> interested in hearing from the mentors how they "promote" stuff from branch
> to trunk.   I was hoping it would be easier:  Instead of a vote, you just
> check it into "develop" and we veto if we don't like it.  Then fewer folks
> have to go look at it.  But that means it might not be quite ready to go to
> production and need to be filtered out before release if we can't get it to
> production quality in time.
>
>
It should be up to a committer to decide when a feature should go from a
feature branch to develop.  We should be able to trust a committer's
judgement for such things.  It will be up to the release manager +
discussion on the mailing list to accept what is in develop to cut into a
release branch.

Om

Re: Discuss: Branching Strategy and SCM

[João Fernandes <jo...@gmail.com>]

Alex but probably there won't be 1 branch / dev, multiple devs will
probably focus on the same branch.

Also, I think it's better to veto before committing to develop no?
I would like to replace [DISCUSSION] by [PROPOSAL], so if anyone developed
/ fixed stuff in their branch, they would launch a [PROPOSAL] thread so
people could chime in regarding the implementation. Afterwards, a [VOTE]
would be created so the implementation could be merged into the Develop
branch.

Is this unrealistic ?

João Fernandes

Re: Discuss: Branching Strategy and SCM

[Alex Harui <ah...@adobe.com>]

On 8/14/12 11:45 AM, "João Fernandes" <jo...@gmail.com>
wrote:

> Alex but couldn't we simply make "[VOTE]/[DISCUSS] - [MERGE]" mandatory
> once we want to merge something to Develop branch?
> 
> João Fernandes
Yes, but in order to vote, I have to get your branch and build it and test
it in order to vote.  40 committers, 40 branches at minimum.  I'd be
interested in hearing from the mentors how they "promote" stuff from branch
to trunk.   I was hoping it would be easier:  Instead of a vote, you just
check it into "develop" and we veto if we don't like it.  Then fewer folks
have to go look at it.  But that means it might not be quite ready to go to
production and need to be filtered out before release if we can't get it to
production quality in time.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Discuss: Branching Strategy and SCM

[João Fernandes <jo...@gmail.com>]

Alex but couldn't we simply make "[VOTE]/[DISCUSS] - [MERGE]" mandatory
once we want to merge something to Develop branch?

João Fernandes

Re: Discuss: Branching Strategy and SCM

[Alex Harui <ah...@adobe.com>]

On 8/14/12 7:51 AM, "Omar Gonzalez" <om...@gmail.com> wrote:

>> 
> Very simple: Publish feature branch to remote repo, send an email to
> flex-dev and say X feature is ready to discuss/dissect/merge to Flex.Next.
> Can also put a STATUS file in the feature branch. Isn't that easy enough?
I can see how GBM can work for a smaller team, but for me, I can't imagine
having to download and build 40 different committer's feature branches in
order to examine their work in order to help guarantee the stability of the
"develop" branch.  I was expecting the "develop" branch to contain some
stuff that wasn't quite baked but at least didn't break the build.  Then new
stuff would be shoved in front of me.  But that would mean you might need to
filter more of it out before releasing.
> 

>> 
>> I would love to believe that we can fully verify something that is in a
>> branch before it gets checked in, but I just don't think it will happen.
>> Folks will need to have their work get some scenario testing and checking
>> in
>> stuff into "develop" that doesn't break anything but may not be complete is
>> to me the easiest option.  I believe we will get more done by taking time
>> to
>> cherry pick at release time rather than trying to manage all of these
>> feature branches and then find they need more baking when finally merged
>> into "develop" and put under real world use.
> 
> 
> If u think that's easier then that's cool, I know I will never volunteer
> time to this project to try and 'cherry pick' stuff from a bunch of devs
> that may or may not still be around for you to ask questions about their
> work. Good luck with that.
> 
> -Omar
That's fine.  If you want to cut a release from the head, you will have to
deal with stuff that isn't quite ready to go, or we will have to be much
more careful about what goes in "develop" than I expected.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Discuss: Branching Strategy and SCM

[Omar Gonzalez <om...@gmail.com>]

On Monday, August 13, 2012, Alex Harui wrote:

>
>
>
> On 8/13/12 10:36 PM, "Omar Gonzalez" <omarg.developer@gmail.com<javascript:;>>
> wrote:
>
> >>
> >> Also the vote added this to the above options - "The release manager can
> >> choose to branch from an older revision and cherry-pick or branch from
> the
> >> head and remove/block certain revisions." Which I have concerns about as
> >> it's not quite how I saw the process as described in the URL.
> >>
> >> Thanks,
> >> Justin
> >
> >
> > That's because that's not how its supposed to work in the GBM.
> >
> >  "The release manager can choose to branch from an older revision and
> > cherry-pick or branch from the head and remove/block certain revisions."
> >
> > This is never mentioned in GBM.
> That's correct.  I added it on purpose, because I don't see how folks will
> be able to decide what goes in Flex.Next as there is no product schedule,
> and with volunteers, you never know when you think you have time and be
> wrong.  This is different from dedicated development where you know at
> release planning time who is working on stuff due for the current release
> and who, if anybody, is on a longer term project.
>
>
Very simple: Publish feature branch to remote repo, send an email to
flex-dev and say X feature is ready to discuss/dissect/merge to Flex.Next.
Can also put a STATUS file in the feature branch. Isn't that easy enough?


> If we take the conservative approach of following GBM as written and do not
> check stuff into the develop branch until you are absolutely sure it is
> ready to go, then you will have delayed sharing or made it harder as we
> have
> to keep switching to different branches in order to try others work.


Again, not accurate. Nothing is stopping a dev from publishing a feature
branch during dev so others can collaborate. THAT'S THE WHOLE POINT OF GBM
AN GIT.


>
> I would love to believe that we can fully verify something that is in a
> branch before it gets checked in, but I just don't think it will happen.
> Folks will need to have their work get some scenario testing and checking
> in
> stuff into "develop" that doesn't break anything but may not be complete is
> to me the easiest option.  I believe we will get more done by taking time
> to
> cherry pick at release time rather than trying to manage all of these
> feature branches and then find they need more baking when finally merged
> into "develop" and put under real world use.


If u think that's easier then that's cool, I know I will never volunteer
time to this project to try and 'cherry pick' stuff from a bunch of devs
that may or may not still be around for you to ask questions about their
work. Good luck with that.

-Omar

Re: Discuss: Branching Strategy and SCM

[Alex Harui <ah...@adobe.com>]

On 8/13/12 10:36 PM, "Omar Gonzalez" <om...@gmail.com> wrote:

>> 
>> Also the vote added this to the above options - "The release manager can
>> choose to branch from an older revision and cherry-pick or branch from the
>> head and remove/block certain revisions." Which I have concerns about as
>> it's not quite how I saw the process as described in the URL.
>> 
>> Thanks,
>> Justin
> 
> 
> That's because that's not how its supposed to work in the GBM.
> 
>  "The release manager can choose to branch from an older revision and
> cherry-pick or branch from the head and remove/block certain revisions."
> 
> This is never mentioned in GBM.
That's correct.  I added it on purpose, because I don't see how folks will
be able to decide what goes in Flex.Next as there is no product schedule,
and with volunteers, you never know when you think you have time and be
wrong.  This is different from dedicated development where you know at
release planning time who is working on stuff due for the current release
and who, if anybody, is on a longer term project.

If we take the conservative approach of following GBM as written and do not
check stuff into the develop branch until you are absolutely sure it is
ready to go, then you will have delayed sharing or made it harder as we have
to keep switching to different branches in order to try others work.

I would love to believe that we can fully verify something that is in a
branch before it gets checked in, but I just don't think it will happen.
Folks will need to have their work get some scenario testing and checking in
stuff into "develop" that doesn't break anything but may not be complete is
to me the easiest option.  I believe we will get more done by taking time to
cherry pick at release time rather than trying to manage all of these
feature branches and then find they need more baking when finally merged
into "develop" and put under real world use.

> 
> In the GBM strategy the dev branch is basically Flex.Next always. The
> master/trunk is always the last stable release to be cut. As features are
> finished they are added to Flex.Next (dev).
> 
> If you complete a feature and you aren't sure it should go into Flex.Next
> yet then you leave the feature in its Feature Branch until you deem it
> ready for Flex.Next.
> 
> In this way you have an easy way of keeping features in a place where they
> can be worked on yet aren't polluting the Flex.Next (dev) branch with
> incomplete or broken features.
> 
> Whenever Flex.Next has enough feature branches merged in that we feel its
> time for a release then that's when a Release Branch is made and everything
> can be updated/fixed that needs to be when prepping a new release. This is
> the branch where Release Candidates would come from. Once its ready to be
> released you tag it and merge it back to Dev, and to trunk. Merging to
> trunk should trigger an automated build for the release product.
> 
> So at no point would you be trying to cherry pick features out of a branch
> to put into a release. They should already be organized in feature branches
> so they're marked as ready for integration when the feature is complete and
> discussed/tested by the Flex comm.
> 
> While I don't think that the process would be nearly as smooth on SVN I do
> believe the concepts could apply in SVN, its just hard for me to say how
> efficient/inefficient it would be because I've never tried that model in
> SVN.
> 
> -omar

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Discuss: Branching Strategy and SCM

[Omar Gonzalez <om...@gmail.com>]

>
> Also the vote added this to the above options - "The release manager can
> choose to branch from an older revision and cherry-pick or branch from the
> head and remove/block certain revisions." Which I have concerns about as
> it's not quite how I saw the process as described in the URL.
>
> Thanks,
> Justin


That's because that's not how its supposed to work in the GBM.

 "The release manager can choose to branch from an older revision and
cherry-pick or branch from the head and remove/block certain revisions."

This is never mentioned in GBM.

In the GBM strategy the dev branch is basically Flex.Next always. The
master/trunk is always the last stable release to be cut. As features are
finished they are added to Flex.Next (dev).

If you complete a feature and you aren't sure it should go into Flex.Next
yet then you leave the feature in its Feature Branch until you deem it
ready for Flex.Next.

In this way you have an easy way of keeping features in a place where they
can be worked on yet aren't polluting the Flex.Next (dev) branch with
incomplete or broken features.

Whenever Flex.Next has enough feature branches merged in that we feel its
time for a release then that's when a Release Branch is made and everything
can be updated/fixed that needs to be when prepping a new release. This is
the branch where Release Candidates would come from. Once its ready to be
released you tag it and merge it back to Dev, and to trunk. Merging to
trunk should trigger an automated build for the release product.

So at no point would you be trying to cherry pick features out of a branch
to put into a release. They should already be organized in feature branches
so they're marked as ready for integration when the feature is complete and
discussed/tested by the Flex comm.

While I don't think that the process would be nearly as smooth on SVN I do
believe the concepts could apply in SVN, its just hard for me to say how
efficient/inefficient it would be because I've never tried that model in
SVN.

-omar

Re: Discuss: Branching Strategy and SCM

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> That would be the 3rd options:
> 7. Git Branching Model (see Description 3) on SVN
> 8. Git Branching Model on SVN now and then on Git (see Note 1)
> 9. Git Branching Model on Git now (see Note 2)

I know  my view is different to some others on the list but this is basically my reasoning re above options:
- Git's has only experimental support by Apache that sounds risky so that's option 9 out for me. 
- I'm not sure that the process would work as described for SVN (Git does branching better) so that's options 7 + 8 out.

It certainly not about Git vs SVN I have no issue working with either and Git does have some clear advantages in general.

Also the vote added this to the above options - "The release manager can choose to branch from an older revision and cherry-pick or branch from the head and remove/block certain revisions." Which I have concerns about as it's not quite how I saw the process as described in the URL.

Thanks,
Justin

Re: Discuss: Branching Strategy and SCM

[Omar Gonzalez <om...@gmail.com>]

> About the only way it can be done without cherry picking is the one
> branch/change (but that wasn't put forward as an option)


That would be the 3rd options:
7. Git Branching Model (see Description 3) on SVN
8. Git Branching Model on SVN now and then on Git (see Note 1)
9. Git Branching Model on Git now (see Note 2)

When executed correctly, the GBM results in a branch per feature, or
hotfix, added to the repository.



> and it's probably a bit excessive/expensive in branching (particularly in
> SVN). Hopefully JIRA may help out here (fixed vs resolved)?
>

Yes, more expensive and tedious in SVN. I wouldn't want to go through JIRA
tickets to try to figure out a release, I definitely would not spend my
time doing that.


>
> Thanks,
> Justin


-omar

Re: Discuss: Branching Strategy and SCM

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> The way I see it, if there are a bunch of developers working in trunk, and
> they happen to leave things unfinished or unstable, then somebody has to go
> through all of that and figure out what is actually ready for a release and
> what is not.
I see that as a concern but I think it's a concern not matter what SCM and branching system we take. We would still somehow have to work out what should be in a release from one or more branches and/or decide how/when features go into a particular branch.

About the only way it can be done without cherry picking is the one branch/change (but that wasn't put forward as an option) and it's probably a bit excessive/expensive in branching (particularly in SVN). Hopefully JIRA may help out here (fixed vs resolved)?

Thanks,
Justin

Re: Discuss: Branching Strategy and SCM

[Omar Gonzalez <om...@gmail.com>]

On Mon, Aug 13, 2012 at 8:25 PM, Om <bi...@gmail.com> wrote:

> On Mon, Aug 13, 2012 at 5:50 PM, Justin Mclean <justin@classsoftware.com
> >wrote:
>
> > Hi,
> >
> > - Unsure how it is decided what from develop/trunk goes into a release.
> > IMO this will make releases a lot more work for the release manager and
> > less likely someone will want to take on that role.
> >
>
> Doesn't option 4 exacerbate this problem?  How can this be a reason to vote
> 'for' option 4?
>

The way I see it, if there are a bunch of developers working in trunk, and
they happen to leave things unfinished or unstable, then somebody has to go
through all of that and figure out what is actually ready for a release and
what is not. Without a well defined SVN strategy this is going to be a mess
that someone will have to clean up.

That is my problem with all of the current strategies being discussed, they
all sound too "from the hip", so to speak. I would not be as opposed to
them if they had clear explanations of how everything is going to happen to
get through the development chain.

-omar

Re: Discuss: Branching Strategy and SCM

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Doesn't option 4 exacerbate this problem?  How can this be a reason to vote
> 'for' option 4?

Also you can branch as needed with option 4.

Thanks,
Justin