SVN and issues with branching / consider how we use SVN going forward

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

Hi,

Suggested way to use Apache SVN:
http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

Note that the suggested options are:
1. Never branch/always use trunk.
2. Branch for each feature and check into trunk when complete.
3. Commit small checkins day to day into trunk. Branch for large changes, checkin in small chunks into branch.

Having a branch that is merged at a regular basis into the trunk is not recommended - although as suggested below it's possible to "bunny hop" (with some disadvantages).

We might want to read and consider the many tales of woe re SVN and branching. 

Same random links - not all woe but give insight into the issues of branching.
http://en.wikipedia.org/wiki/Apache_Subversion (see limitation and issues)
http://designbygravity.wordpress.com/2009/10/19/what-mother-never-told-you-about-svn-branching-and-merging/
http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
http://stackoverflow.com/search?q=svn+merge
http://subclipse.tigris.org/branch_tag.html 

Subclipse makes it a little easier but not everyone uses it - see overview in link above to why branching can be an issue.

IMO If we were to going down the path of a single unstable branch all committers would have 2 full checkouts (one trunk and one on the branch) and pay very careful attention to revision numbers (as you need to use them when merging) to have a chance of going smoothly. 

Thanks,
Justin

Re: SVN and issues with branching / consider how we use SVN going forward

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Aug 7, 2012 at 5:09 PM, Alex Harui <ah...@adobe.com> wrote:
> On 8/7/12 1:23 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>> ...From the community standpoint, I think working in the same trunk as
>> much as possible is much better, in general....

> So you are not a fan of the whiteboard->unstable->trunk approach?  Or just
> not having a ton of personal branches. I thought some Apache projects used
> the tiered approach....

In the projects where I'm active, whiteboard is just here for wild
experiments that are usually short-lived and also usually mostly
rewritten before making it to the trunk. Think of it as a whiteboard
on the wall in the meeting room, where you go wild, take pictures to
remember the good ideas and erase the whole thing when you leave.

I'm not sure about having both a trunk and a stable branch - if you
have solid tests, trunk should be releasable 99% of the time, and if
you can attain that it's a great motivation for developers to work
without breaking things (most of the time of course).

Just my two cents, I'm not saying this with any "mentor authority",
just from my experience in various projects at the ASF.

-Bertrand

Re: SVN and issues with branching / consider how we use SVN going forward

[Carlos Rovira <ca...@codeoscopic.com>]

> If it's possible, yes, I really do think Git would help.

As Michael and Om says Git would be an improvement over SVN. At work, we
switched to Git some months ago and the overall experience is great. We
have more control about how code evolve over time taking into account that
we have many hands in different teams working in different branches. The
way we work today would be impossible with old SVN.

Flex is reaching version 5, and that means we need to change core things
(UIComponent, HTLM5 approach,...) that touch many other things and take
several time, ...and continue with normal small modification and addition
changes. At this point Git would be a better option than SVN since
committers could branch an isolate his work in an efficient way. Git has
several tools to make this easy (staging, stashing, cherry picks, and so
on...)

Other thing that would be possible with Git is that part of the team
(PPMC?) could control what commits goes to the main branch and the ones
that are not eligible, and contributors could send the commit without the
need to be applied directly to the final product. I'm with Alex, that some
patches could "work for me" but could break other things (something that
mustella could detect...or not) and, with Flex as a mature framework, will
be necessary to have people monitoring this.

SVN seems ok when project are starting...but for mature software that needs
to evolve things that was developed years ago and need to be rethinked and
rewritten affecting several parts of the entire software...Git is the
option.

Take into account that Git needs some "mind change" from the people that
comes from SVN since the philosophy behind changes and is what makes the
system great.

If we vote my "non binding" vote will go to git without doubt :)

Best

Carlos Rovira

Re: SVN and issues with branching / consider how we use SVN going forward

[Jeffry Houser <je...@dot-com-it.com>]

On 8/9/2012 11:15 AM, Dave Fisher wrote:
> On Aug 9, 2012, at 8:06 AM, Greg Reddin wrote:
>
>> On Wed, Aug 8, 2012 at 6:15 PM, Dave Fisher <da...@comcast.net> wrote:
>>> I totally agree. Maintaining an unstable version will actually make more work. Just when you think it is stable enough to move into trunk, you have to make it stable again in trunk.
>>>
>>> The community should be perfectly capable of deciding when trunk should be made stable for an upcoming release and stop making ill considered changes.
>> We argued about this for days at $work, then we finally stumbled on a
>> solution. Flip the model around. Trunk becomes the unstable, do
>> whatever you want, development branch. Create a separate stable or
>> release branch where code gets "promoted" to.
>>
>> The process is still evolving. We haven't quite figured out the best
>> way to "promote" code in svn. Here's what I *think* we'll move to
>> pretty soon:
>>
>> 1. Trunk is still the unstable development branch.
>> 2. People create feature branches for work that can't be completed in
>> short order. Merge often from trunk to your feature branch.
>>     2a. When feature branch is done, merge --reintegrate back to trunk.
>> 3. Trunk is always pretty close to being ready to release even though
>> it is considered unstable.
>> 4. When we are close to a release we restrict changes on trunk to
>> those related to the release.
>> 5. Tag releases.
>> 6. For a patch/bugfix release create a branch from the previous tag.
>> Make the bugfix in the branch. Be sure to make it in trunk also
>> (sometimes it's easier to make the change in trunk then merge it to
>> the branch).
>>     6a. Tag the patch/bugfix release
>>
>> Not fully fleshed out, but a basic plan.
> That is pretty much what I do at work as well.

  That is what I've been doing lately w/ one of my clients.  We develop 
in trunk; and whenever we do a release, we create a tag of the trunk 
code.  We haven't been using branches at all.


-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: SVN and issues with branching / consider how we use SVN going forward

[Dave Fisher <da...@comcast.net>]

On Aug 9, 2012, at 8:06 AM, Greg Reddin wrote:

> On Wed, Aug 8, 2012 at 6:15 PM, Dave Fisher <da...@comcast.net> wrote:
>> I totally agree. Maintaining an unstable version will actually make more work. Just when you think it is stable enough to move into trunk, you have to make it stable again in trunk.
>> 
>> The community should be perfectly capable of deciding when trunk should be made stable for an upcoming release and stop making ill considered changes.
> 
> We argued about this for days at $work, then we finally stumbled on a
> solution. Flip the model around. Trunk becomes the unstable, do
> whatever you want, development branch. Create a separate stable or
> release branch where code gets "promoted" to.
> 
> The process is still evolving. We haven't quite figured out the best
> way to "promote" code in svn. Here's what I *think* we'll move to
> pretty soon:
> 
> 1. Trunk is still the unstable development branch.
> 2. People create feature branches for work that can't be completed in
> short order. Merge often from trunk to your feature branch.
>    2a. When feature branch is done, merge --reintegrate back to trunk.
> 3. Trunk is always pretty close to being ready to release even though
> it is considered unstable.
> 4. When we are close to a release we restrict changes on trunk to
> those related to the release.
> 5. Tag releases.
> 6. For a patch/bugfix release create a branch from the previous tag.
> Make the bugfix in the branch. Be sure to make it in trunk also
> (sometimes it's easier to make the change in trunk then merge it to
> the branch).
>    6a. Tag the patch/bugfix release
> 
> Not fully fleshed out, but a basic plan.

That is pretty much what I do at work as well. It also fits what is done in Apache POI and Apache OpenOffice. With Apache OpenOffice, OpenOffice.org had been recently converted from SVN to HG (Mercurial) before the Oracle donation. There are huge workspace branches, a selected set of these got merged to trunk. Now individuals branch for large changes. Lessons are currently being learned with the second release, but that is mostly about not being so quick to roll a new RC every time a showstopper is fixed in trunk. AOO is a huge codebase.

Regards,
Dave

> 
> Greg

Re: SVN and issues with branching / consider how we use SVN going forward

[Carol Frampton <cf...@adobe.com>]

On 8/9/12 11 :06AM, "Greg Reddin" <gr...@gmail.com> wrote:

>On Wed, Aug 8, 2012 at 6:15 PM, Dave Fisher <da...@comcast.net> wrote:
>> I totally agree. Maintaining an unstable version will actually make
>>more work. Just when you think it is stable enough to move into trunk,
>>you have to make it stable again in trunk.
>>
>> The community should be perfectly capable of deciding when trunk should
>>be made stable for an upcoming release and stop making ill considered
>>changes.
>
>We argued about this for days at $work, then we finally stumbled on a
>solution. Flip the model around. Trunk becomes the unstable, do
>whatever you want, development branch. Create a separate stable or
>release branch where code gets "promoted" to.
>
>The process is still evolving. We haven't quite figured out the best
>way to "promote" code in svn. Here's what I *think* we'll move to
>pretty soon:
>
>1. Trunk is still the unstable development branch.
>2. People create feature branches for work that can't be completed in
>short order. Merge often from trunk to your feature branch.
>    2a. When feature branch is done, merge --reintegrate back to trunk.
>3. Trunk is always pretty close to being ready to release even though
>it is considered unstable.
>4. When we are close to a release we restrict changes on trunk to
>those related to the release.
>5. Tag releases.
>6. For a patch/bugfix release create a branch from the previous tag.
>Make the bugfix in the branch. Be sure to make it in trunk also
>(sometimes it's easier to make the change in trunk then merge it to
>the branch).
>    6a. Tag the patch/bugfix release
>
>Not fully fleshed out, but a basic plan.

I believe this is exactly what I just read in
http://nvie.com/posts/a-successful-git-branching-model/ with the exception
being at your #4 you would create a release branch and allow development
to continue on trunk.  When released, a tag would be created for the
release branch and any changes made on the release branch would be merged
back to trunk.

I think this is exactly what we did at Adobe.  The only difference is we
had a branch for each release and in this model I think you could keep
using the same release branch for each release, merging changes from trunk
to the release branch at the start of the cycle and then reintegrating the
changes back to trunk at the end of the cycle.

When you see it laid out in the diagram in the article it makes a lot of
sense especially since it seems pretty clear to me that some people want
to do work which will take awhile and span a release cycle.

The one thing we learned about svn merge is that when you merge you always
have to do it from root so all the merge records get written at the root
and it is easier to keep track of what has been merged and what hasn't.

Carol

Re: SVN and issues with branching / consider how we use SVN going forward

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

On Wed, Aug 8, 2012 at 6:15 PM, Dave Fisher <da...@comcast.net> wrote:
> I totally agree. Maintaining an unstable version will actually make more work. Just when you think it is stable enough to move into trunk, you have to make it stable again in trunk.
>
> The community should be perfectly capable of deciding when trunk should be made stable for an upcoming release and stop making ill considered changes.

We argued about this for days at $work, then we finally stumbled on a
solution. Flip the model around. Trunk becomes the unstable, do
whatever you want, development branch. Create a separate stable or
release branch where code gets "promoted" to.

The process is still evolving. We haven't quite figured out the best
way to "promote" code in svn. Here's what I *think* we'll move to
pretty soon:

1. Trunk is still the unstable development branch.
2. People create feature branches for work that can't be completed in
short order. Merge often from trunk to your feature branch.
    2a. When feature branch is done, merge --reintegrate back to trunk.
3. Trunk is always pretty close to being ready to release even though
it is considered unstable.
4. When we are close to a release we restrict changes on trunk to
those related to the release.
5. Tag releases.
6. For a patch/bugfix release create a branch from the previous tag.
Make the bugfix in the branch. Be sure to make it in trunk also
(sometimes it's easier to make the change in trunk then merge it to
the branch).
    6a. Tag the patch/bugfix release

Not fully fleshed out, but a basic plan.

Greg

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/8/12 4:15 PM, "Dave Fisher" <da...@comcast.net> wrote:


> 
> The community should be perfectly capable of deciding when trunk should be
> made stable for an upcoming release and stop making ill considered changes.
> 
I would love for that to be true, but historically it hasn't.  We've taken
several community patches that seemed good when reviewed but then caused
problems at crunch time.  I believe that will be solved with better test
development over time, but I don't think we're there now.

> 
> Tag releases and turn those into branches if you need to have something ready
> to release a dot version on.
Have you seen any good discussions on why some other projects have
apparently chosen to keep trunk "ready-to-ship"?

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

Re: SVN and issues with branching / consider how we use SVN going forward

[Dave Fisher <da...@comcast.net>]

On Aug 7, 2012, at 1:23 AM, Bertrand Delacretaz wrote:

> On Tue, Aug 7, 2012 at 9:08 AM, Alex Harui <ah...@adobe.com> wrote:
>> ...IIRC, merging worked pretty well for us.  I am currently not afraid of it,
>> especially since we are using SVN 1.6....
> 
> From the community standpoint, I think working in the same trunk as
> much as possible is much better, in general.
> 
> Even if branching/merging is not a problem from the technical point of
> view, IMO branches should be as short lived as possible, and only
> created when really needed. Long-lived branches can create much
> technical and community friction IMO, and learning to work in small
> reversible steps that don't hurt other's code can help the overall
> project velocity a lot.

I totally agree. Maintaining an unstable version will actually make more work. Just when you think it is stable enough to move into trunk, you have to make it stable again in trunk.

The community should be perfectly capable of deciding when trunk should be made stable for an upcoming release and stop making ill considered changes.

If the community works on trunk then there won't be much of a question about where a contributor should work.

It really is good to avoid extra process.

Tag releases and turn those into branches if you need to have something ready to release a dot version on.

Regards,
Dave


> 
> -Bertrand

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/8/12 12:34 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:

> On Wed, Aug 8, 2012 at 7:32 AM, Alex Harui <ah...@adobe.com> wrote:
>> ...If you are 100% sure your change is safe, I won't veto it if you
>> commit it to both branches at the same time.  If you're wrong, we will
>> resort to public humiliation like other projects do....
> 
> There's no need to humiliate people who do something wrong. Just ask
> them to fix it or revert their changes.
> 
> -Bertrand
My apologies.

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

Re: SVN and issues with branching / consider how we use SVN going forward

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Aug 8, 2012 at 7:32 AM, Alex Harui <ah...@adobe.com> wrote:
> ...If you are 100% sure your change is safe, I won't veto it if you
> commit it to both branches at the same time.  If you're wrong, we will
> resort to public humiliation like other projects do....

There's no need to humiliate people who do something wrong. Just ask
them to fix it or revert their changes.

-Bertrand

Re: SVN and issues with branching / consider how we use SVN going forward

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

On Wednesday, August 8, 2012, Alex Harui wrote:

>
>
>
> On 8/8/12 12:33 AM, "Bertrand Delacretaz" <bdelacretaz@apache.org<javascript:;>>
> wrote:
>
> > On Wed, Aug 8, 2012 at 9:27 AM, Justin Mclean <justin@classsoftware.com<javascript:;>
> >
> > wrote:
> > Alex wrote:
> >>> Let's use the unstable branch until we prove we don't need it.
> >
> >> You want to work that way go ahead I will not be using it.
> >
> > This is a typical case were consensus is hard to reach - I suggest
> > exposing both options as concisely as possible and starting a new
> > [POLL] thread where other committers can express their preferences.
> >
> > -Bertrand
> OK, I will start a POLL.  But what good will it do if others refuse to
> abide
> by it?  I can't veto his commit on technical basis, he just has a different
> approach he wants to use.  Basically those who don't want to use an interim
> branch can simply make it not work for everyone else.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui


I agree with Alex. It's no use to come up with an approach if some people
are going to run against the grain anyhow and do things their way.

I think using a single trunk is a mistake. Like Alex said, yes there are
10000 Mustella tests, obviously it's not enough with over 30000 defects in
JIRA. I would vote for separate branches. I'd go as far as making
integration branches for each patch submitted to run tests against that
patch and make sure nothing is broken that shouldn't be.

Either way, everyone has to buy in to whatever the consensus is, or it's
going to be a clusterfuck.

-omar

Re: SVN and issues with branching / consider how we use SVN going forward

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Aug 8, 2012 at 5:25 PM, Alex Harui <ah...@adobe.com> wrote:
> ....OK, I will start a POLL.  But what good will it do if others refuse to abide
> by it?  I can't veto his commit on technical basis, he just has a different
> approach he wants to use...

Once the PPMC makes a decision, people have to abide by it even if
they disagree. Or find new ways to convince others.

-Bertrand

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/8/12 12:33 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:

> On Wed, Aug 8, 2012 at 9:27 AM, Justin Mclean <ju...@classsoftware.com>
> wrote:
> Alex wrote:
>>> Let's use the unstable branch until we prove we don't need it.
> 
>> You want to work that way go ahead I will not be using it.
> 
> This is a typical case were consensus is hard to reach - I suggest
> exposing both options as concisely as possible and starting a new
> [POLL] thread where other committers can express their preferences.
> 
> -Bertrand
OK, I will start a POLL.  But what good will it do if others refuse to abide
by it?  I can't veto his commit on technical basis, he just has a different
approach he wants to use.  Basically those who don't want to use an interim
branch can simply make it not work for everyone else.

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

Re: SVN and issues with branching / consider how we use SVN going forward

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Aug 8, 2012 at 9:27 AM, Justin Mclean <ju...@classsoftware.com> wrote:
Alex wrote:
>> Let's use the unstable branch until we prove we don't need it.

> You want to work that way go ahead I will not be using it.

This is a typical case were consensus is hard to reach - I suggest
exposing both options as concisely as possible and starting a new
[POLL] thread where other committers can express their preferences.

-Bertrand

Re: SVN and issues with branching / consider how we use SVN going forward

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

>
>
> The author of the article seemed to want to make a release branch so that
> whatever hits the trunk is essentially a snapshot of a release.  I'm not
> quite sure that is worth it if at the point there is a group of us
> dedicated
> to making a release and fixing things that are broken.


The point of the release branches are to prepare what is in the dev/trunk
branch for release. That would include changing the build number, updating
a change log, fixing docs, those types of minor changes that come with
making a release. Even very minor bug changes can be done in a release
branch. Once its ready to be shipped you push to dev/trunk which should
trigger a Jenkins build which produces a new version of the product. If you
continually make the small changes in dev/trunk then your continuously
making new versions of the product, so the idea of the release branch is
just to make those small changes and get it ready to 'go out the door'.
Once it goes out the door you tag it and that's the EOL for the release
branch.

-omar

Re: SVN and issues with branching / consider how we use SVN going forward

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

>
> t saying it is worth it in order to protect the integrity of trunk.
>
> If it's possible, yes, I really do think Git would help. The reason is
> that dealing with merge issues in Git are infinitely easier and, at least
> 95% of the time, keeps us out of the merge-hell that I think Justin
> legitimately fears.
>
> The one nice thing about the release and feature branches is that it
> allows people to start working toward future releases and grand visions
> while a current release is being stabilized. For example the code many had
> in whiteboards that was destined for future releases.
>
> Mike
>
>
I agree with all of this. I would be completely in favor of making Git the
primary SCM for the project, it would really make a lot of these workflows
easier to manage amongst so many developers. I also posted about the link
Mike shared and that model has worked great for our teams.

-omar

Re: SVN and issues with branching / consider how we use SVN going forward

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

>
> t saying it is worth it in order to protect the integrity of trunk.
>
> If it's possible, yes, I really do think Git would help. The reason is
> that dealing with merge issues in Git are infinitely easier and, at least
> 95% of the time, keeps us out of the merge-hell that I think Justin
> legitimately fears.
>
> The one nice thing about the release and feature branches is that it
> allows people to start working toward future releases and grand visions
> while a current release is being stabilized. For example the code many had
> in whiteboards that was destined for future releases.
>
> Mike
>
>
I agree with all of this. I would be completely in favor of making Git the
primary SCM for the project, it would really make a lot of these workflows
easier to manage amongst so many developers. I also posted about the link
Mike shared and that model has worked great for our teams.

-omar

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/8/12 11:36 AM, "labriola@digitalprimates.net"
<la...@digitalprimates.net> wrote:

> 
> The one nice thing about the release and feature branches is that it allows
> people to start working toward future releases and grand visions while a
> current release is being stabilized. For example the code many had in
> whiteboards that was destined for future releases.
> 
> Mike
> 
The author of the article seemed to want to make a release branch so that
whatever hits the trunk is essentially a snapshot of a release.  I'm not
quite sure that is worth it if at the point there is a group of us dedicated
to making a release and fixing things that are broken.  I wasn't thinking
we'd need to restrict checkins to unstable around release time if we are
being selective about what changes get promoted to trunk.  But if that
doesn't work out, then we would probably need to have release branches.

Feature branches are certainly ok in anyone's whiteboard or in branches, but
I don't know if we need policy around it.

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

RE: SVN and issues with branching / consider how we use SVN going forward

["Michael A. Labriola" <la...@digitalprimates.net>]

>Interesting read.  Are you also pushing to make Git the default SCM?
>
>I'm not sure how far away we are from this model in some respects.  We have whiteboards which sort of decentralize new development, and I am proposing an "unstable" branch that maps to the "develop" >branch in the article (and "master" is "trunk").
>
>I don't know that I'd go with release branches if we can get enough folks to pound on the promotions from unstable to trunk when they go in.
>
>And to answer Justin's question, merging by revision number worked pretty well for us.  But yes, every once in a while you will hit merge-hell.  I'm just saying it is worth it in order to protect the integrity of trunk.

If it's possible, yes, I really do think Git would help. The reason is that dealing with merge issues in Git are infinitely easier and, at least 95% of the time, keeps us out of the merge-hell that I think Justin legitimately fears.

The one nice thing about the release and feature branches is that it allows people to start working toward future releases and grand visions while a current release is being stabilized. For example the code many had in whiteboards that was destined for future releases.

Mike

Re: SVN and issues with branching / consider how we use SVN going forward

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Aug 8, 2012 at 7:10 PM, Om <bi...@gmail.com> wrote:
Alex wrote:
>> ...Are you also pushing to make Git the default SCM?
>>...
> Is that an option available to us?  If yes, I think moving to Git would
> make a lot of sense.  If it is not, please forget that I asked...

Some Apache projects are working with Git as their main code
repository, so yes that's possible.

But I don't think that would solve the community problem of "what goes
in trunk".

-Bertrand

Re: SVN and issues with branching / consider how we use SVN going forward

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

>
> > http://nvie.com/posts/a-successful-git-branching-model/
> >
> > Just ponder it. It does work in practice.
> >
> > Mike
> >
> Interesting read.  Are you also pushing to make Git the default SCM?
>
> >
Is that an option available to us?  If yes, I think moving to Git would
make a lot of sense.  If it is not, please forget that I asked.

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/8/12 9:14 AM, "labriola@digitalprimates.net"
<la...@digitalprimates.net> wrote:

>> So again I ask.  How do you intend you merge from unstable to trunk persons A
>> changes when the unstable branch containts persons A, B, C, D, E and F
>> changes and each may of made multiple check ins at different times. As far
>> >as I'm aware there's no easy way to do it (even if you look up exact
>> revision numbers).
> 
> Just as another thought, this is the basic model we use when using Git. It
> won't work as well with SVN, as easy branching is Git's killer feature...
> however, maybe that is an argument for a change of direction:
> 
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> Just ponder it. It does work in practice.
> 
> Mike
> 
Interesting read.  Are you also pushing to make Git the default SCM?

I'm not sure how far away we are from this model in some respects.  We have
whiteboards which sort of decentralize new development, and I am proposing
an "unstable" branch that maps to the "develop" branch in the article (and
"master" is "trunk").

I don't know that I'd go with release branches if we can get enough folks to
pound on the promotions from unstable to trunk when they go in.

And to answer Justin's question, merging by revision number worked pretty
well for us.  But yes, every once in a while you will hit merge-hell.  I'm
just saying it is worth it in order to protect the integrity of trunk.


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

RE: SVN and issues with branching / consider how we use SVN going forward

["Michael A. Labriola" <la...@digitalprimates.net>]

>So again I ask.  How do you intend you merge from unstable to trunk persons A changes when the unstable branch containts persons A, B, C, D, E and F changes and each may of made multiple check ins at different times. As far >as I'm aware there's no easy way to do it (even if you look up exact revision numbers).

Just as another thought, this is the basic model we use when using Git. It won't work as well with SVN, as easy branching is Git's killer feature... however, maybe that is an argument for a change of direction:

http://nvie.com/posts/a-successful-git-branching-model/

Just ponder it. It does work in practice.

Mike

Re: SVN and issues with branching / consider how we use SVN going forward

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

HI,

> I think I misspoke.  We were merging by revision numbers not changelists.
So again I ask.  How do you intend you merge from unstable to trunk persons A changes when the unstable branch containts persons A, B, C, D, E and F changes and each may of made multiple check ins at different times. As far as I'm aware there's no easy way to do it (even if you look up exact revision numbers).

> Let's use the unstable branch until we prove we don't need it.
You want to work that way go ahead I will not be using it.

Justin

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/7/12 11:57 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
> From my experience I'd not recommend using changelists. IMO they are can be
> confusing, have limited GUI tool support, are only client side (ie can't be
> shared or checked in), only work with files (not directories) and have issues
> with non flat directory structures.
> 
> For those who don't know about SVN changelists (and I'd guess there's a few)
> you can read more here:
> http://svnbook.red-bean.com/en/1.6/svn.advanced.changelists.html
> 
> How about instead of going down the most complex path right away - lets try
> the simple way (ie use trunk) and if we have any issues then consider what
> needs to be done?
> 
> I would rather my time was taking up writing code not juggling changelists and
> branches and fighting with SVN when things don't work.
> 
I think I misspoke.  We were merging by revision numbers not changelists.

I would rather err on the side of being able to quickly produce quality
releases and think the extra effort is going to be worth it.  If we go with
your plan and are sorry, it will be much harder to recover.

Let's use the unstable branch until we prove we don't need it.

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

Re: SVN and issues with branching / consider how we use SVN going forward

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

Hi,

From my experience I'd not recommend using changelists. IMO they are can be confusing, have limited GUI tool support, are only client side (ie can't be shared or checked in), only work with files (not directories) and have issues with non flat directory structures.

For those who don't know about SVN changelists (and I'd guess there's a few) you can read more here:
http://svnbook.red-bean.com/en/1.6/svn.advanced.changelists.html

How about instead of going down the most complex path right away - lets try the simple way (ie use trunk) and if we have any issues then consider what needs to be done?

I would rather my time was taking up writing code not juggling changelists and branches and fighting with SVN when things don't work.

Thanks,
Justin

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/7/12 4:32 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>> Unfortunately, Flex isn't as modular as it should be.
> Perhaps not on the large scale architecture level. But I still see no issue
> with checking fixes to JIRA issues or new components (tested obviously) into
> trunk as they would be small bite sized chunks (and generally low risk), even
> changes to existing components should be able to be done in bite size chunks,
> for major architecture changes I would expect a branch.
I say we play it safe and use an unstable branch for now and prove we don't
need it.  If you are 100% sure your change is safe, I won't veto it if you
commit it to both branches at the same time.  If you're wrong, we will
resort to public humiliation like other projects do.
> 
>>  And given that I don't think we have enough tests to keep trunk in good
>> shape
> How many Mustella tests just got checked in? 10,000? As all development is in
> public you get many people eyes on each check in. Changes to trunk can be very
> easily reverted if needed.
More than 10000 mustella tests exist, but if we had enough tests, there
wouldn't be 30,000 bugs in JIRA.
> 
>> I'd lean towards playing it safe with an unstable branch until we can prove
>> that we can keep it in shape.
> Let say we go with this. At any one time you may have several people patches
> etc  in unstable and if it's decided that one is good enough to put into trunk
> how do you merge that patch into trunk and not the other patches?
You can merge individual change lists.  We did this all the time at Adobe.
Most of the time it worked.
> Even if the 
> patches are in different parts of the code I can see issues here. How do we
> know when the unstable branch isn't broken?
We can even merge certain changelists while unstable is broken as long as ou
aren't merge the thing that broke it.
> Do we need to set up more CI
> instances one for unstable and another for any other long running branch?
Yes, one instance for unstable and one for trunk.  I'm not seeing a need for
more long-running branches at this time.
> Do 
> we need to run Mustella over both trunk and unstable before doing a merge?
I would say no.
> 
> Justin
> 


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

Re: SVN and issues with branching / consider how we use SVN going forward

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

Hi,

> Unfortunately, Flex isn't as modular as it should be.
Perhaps not on the large scale architecture level. But I still see no issue with checking fixes to JIRA issues or new components (tested obviously) into trunk as they would be small bite sized chunks (and generally low risk), even changes to existing components should be able to be done in bite size chunks, for major architecture changes I would expect a branch.

>  And given that I don't think we have enough tests to keep trunk in good shape
How many Mustella tests just got checked in? 10,000? As all development is in public you get many people eyes on each check in. Changes to trunk can be very easily reverted if needed.

> I'd lean towards playing it safe with an unstable branch until we can prove that we can keep it in shape.
Let say we go with this. At any one time you may have several people patches etc  in unstable and if it's decided that one is good enough to put into trunk how do you merge that patch into trunk and not the other patches? Even if the patches are in different parts of the code I can see issues here. How do we know when the unstable branch isn't broken? Do we need to set up more CI instances one for unstable and another for any other long running branch?  Do we need to run Mustella over both trunk and unstable before doing a merge?

Justin

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/7/12 9:02 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:

> On Tue, Aug 7, 2012 at 5:52 PM, Carol Frampton <cf...@adobe.com> wrote:
>> ...if you are working on a feature that will take you
>> some time to complete (or more than a release cycle) and you can't break
>> it down into useable sub-pieces, and you want to check in at intermediate
>> points, the code needs to go somewhere other than trunk....
> 
> IMO the key is "can't break it into useable sub-pieces" - that's
> usually a sign of something being wrong at the design level, which
> might happen from time to time but shouldn't be the rule.
> 
> I often take the extreme modularity of httpd.apache.org as an example
> to follow: making things more modular allows people to work in
> parallel without stepping on each other's toes, and also dramatically
> reduces the amount of coordination that's needed to work efficiently.
> Maybe Flex needs a bit of that to make it easier to collaborate - I
> don't know the codebase enough to comment on that.
> 
> -Bertrand
Unfortunately, Flex isn't as modular as it should be.  And given that I
don't think we have enough tests to keep trunk in good shape, I'd lean
towards playing it safe with an unstable branch until we can prove that we
can keep it in shape.

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

Re: SVN and issues with branching / consider how we use SVN going forward

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Aug 7, 2012 at 5:52 PM, Carol Frampton <cf...@adobe.com> wrote:
> ...if you are working on a feature that will take you
> some time to complete (or more than a release cycle) and you can't break
> it down into useable sub-pieces, and you want to check in at intermediate
> points, the code needs to go somewhere other than trunk....

IMO the key is "can't break it into useable sub-pieces" - that's
usually a sign of something being wrong at the design level, which
might happen from time to time but shouldn't be the rule.

I often take the extreme modularity of httpd.apache.org as an example
to follow: making things more modular allows people to work in
parallel without stepping on each other's toes, and also dramatically
reduces the amount of coordination that's needed to work efficiently.
Maybe Flex needs a bit of that to make it easier to collaborate - I
don't know the codebase enough to comment on that.

-Bertrand

Re: SVN and issues with branching / consider how we use SVN going forward

[Carol Frampton <cf...@adobe.com>]

On 8/7/12 11 :09AM, "Alex Harui" <ah...@adobe.com> wrote:

>
>
>
>On 8/7/12 1:23 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>
>> On Tue, Aug 7, 2012 at 9:08 AM, Alex Harui <ah...@adobe.com> wrote:
>>> ...IIRC, merging worked pretty well for us.  I am currently not afraid
>>>of it,
>>> especially since we are using SVN 1.6....
>> 
>> From the community standpoint, I think working in the same trunk as
>> much as possible is much better, in general.
>So you are not a fan of the whiteboard->unstable->trunk approach?  Or just
>not having a ton of personal branches. I thought some Apache projects used
>the tiered approach.

I don't think everything has to go thru unstable but I think the code that
goes into trunk has to be complete and bug-free to the best of your
knowledge.  That means if you are working on a feature that will take you
some time to complete (or more than a release cycle) and you can't break
it down into useable sub-pieces, and you want to check in at intermediate
points, the code needs to go somewhere other than trunk.

I think it is possible to do svn merging correctly but many people don't.
At Adobe, the engineers did their own merging but we had a build engineer
who cleaned up after us.

Carol

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

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/7/12 1:23 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:

> On Tue, Aug 7, 2012 at 9:08 AM, Alex Harui <ah...@adobe.com> wrote:
>> ...IIRC, merging worked pretty well for us.  I am currently not afraid of it,
>> especially since we are using SVN 1.6....
> 
> From the community standpoint, I think working in the same trunk as
> much as possible is much better, in general.
So you are not a fan of the whiteboard->unstable->trunk approach?  Or just
not having a ton of personal branches. I thought some Apache projects used
the tiered approach.

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

Re: SVN and issues with branching / consider how we use SVN going forward

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Aug 7, 2012 at 9:08 AM, Alex Harui <ah...@adobe.com> wrote:
> ...IIRC, merging worked pretty well for us.  I am currently not afraid of it,
> especially since we are using SVN 1.6....

>From the community standpoint, I think working in the same trunk as
much as possible is much better, in general.

Even if branching/merging is not a problem from the technical point of
view, IMO branches should be as short lived as possible, and only
created when really needed. Long-lived branches can create much
technical and community friction IMO, and learning to work in small
reversible steps that don't hurt other's code can help the overall
project velocity a lot.

-Bertrand

Re: SVN and issues with branching / consider how we use SVN going forward

[Dave Fisher <da...@comcast.net>]

On Aug 6, 2012, at 8:38 PM, Justin Mclean wrote:

> Hi,
> 
> JFYI there may be less issue with more recent versions of SVN and branching.
> 
> In that you can keep branches up to date like so:
> svn merge pathtotrunk
> 
> And then merging via:
> svn merge --reintegrate pathtobranch
> 
> Any tired this? How does it work in practise?

Developing on trunk all you need to do is:

svn up
svn add
svn status
svn commit

Really I hardly need to merge. If you svn up often you resolve any conflicts early. You can discuss any questions on the list.

Regards,
Dave

> 
> Thanks,
> Justin

Re: SVN and issues with branching / consider how we use SVN going forward

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

Hi,

> I've personally always kept my trunk as the stable, and merged changes into
> it from other places with little ill-effect.
Just out of interest multiple developers/single developer or multiple branches/single branch? Any once a branch is merged do you continue to make changes in it?

Thanks,
Justin

Re: SVN and issues with branching / consider how we use SVN going forward

[Nicholas Kwiatkowski <ni...@spoon.as>]

I've personally always kept my trunk as the stable, and merged changes into
it from other places with little ill-effect.  The only problem is if you
get a bad commit (it happens, sometimes the software screws up and issues a
commit number to the svn client but doesn't save the changes), then
everything goes haywire.

-Nick

On Mon, Aug 6, 2012 at 11:38 PM, Justin Mclean <ju...@classsoftware.com>wrote:

> Hi,
>
> JFYI there may be less issue with more recent versions of SVN and
> branching.
>
> In that you can keep branches up to date like so:
> svn merge pathtotrunk
>
> And then merging via:
> svn merge --reintegrate pathtobranch
>
> Any tired this? How does it work in practise?
>
> Thanks,
> Justin
>

Re: SVN and issues with branching / consider how we use SVN going forward

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

Hi,

> IIRC, merging worked pretty well for us.  I am currently not afraid of it,
> especially since we are using SVN 1.6.
But was it the same setup? ie a single branch in which you merged with the trunk at regular intervals? As per Apache SVN's documentation this is not recommended. Merging with branches has also work for me in the past but it can be a barrier to productivity.

> The designbygravity post is somewhat outdated and it appears that SVN 1.6
> obsoletes it.
Somewhat yes (and I noted in my followup) but my point about a single branch still stands.

> In my experience reviewing patches from the community, fixes often need
> 'fixing' or will be vetoed.  
As all development is in the open (unlike before) so that will happen no matter what branch code goes into. There's nothing particularly special about trunk other than it what we make releases from. Any patch can be reverted/modified if needed by someone if required.

>  But my experience with the SDK is that we have so
> many different types of customers that cannot keep up on the latest that
> having really good releases is very important.
We're not asking customers to update every release and I'm sure some will skip a few.  All releases should be of good quality code - that goes without saying. The issue I see with long release cycles is that not much progress is seen as been made, shorten the time between release shows there's stuff going on. A balance is needed between the two obviously.

> I think we have different experiences and philosophies here and will
> probably never agree. 
Fair enough. Let put it to a vote then. Basically do we follow one of the Apache SVN recommend processes (1-3 in the Apache SVN best practices page) or use a single branch as you suggested? As noted in coding horror link the choice is basically between productivity and risk. I thank that with limited resources and time it's more important to be productive, you take the position that it better to take less risk, both are certainly valid views. I don't think we can mix and match approaches. If using a a single branch it's quite possible than any single check in to trunk with cause merge issues down the track with a separate branch.

> Can you explain why the freezed caused more issues?
Sure basically:
1. People racing to check stuff in before the freeze results in poor quality code.
2. Unable to fix bugs in trunk once the freeze has happened.
3. Integration issues (see big bang anti pattern).
4. All other useful work stops while build issues are sorted out.

> I don't think you can use the patches merge as typical.  
Perhaps not typical but it should of worked. I ended up giving up and reapply the changes by hand some SVN history was lost as a result.

Thanks,
Justin

Re: SVN and issues with branching / consider how we use SVN going forward

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

On 8/6/12 8:38 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
> JFYI there may be less issue with more recent versions of SVN and branching.
> 
> In that you can keep branches up to date like so:
> svn merge pathtotrunk
> 
> And then merging via:
> svn merge --reintegrate pathtobranch
> 
> Any tired this? How does it work in practise?
> 
> Thanks,
> Justin
IIRC, merging worked pretty well for us.  I am currently not afraid of it,
especially since we are using SVN 1.6.

The designbygravity post is somewhat outdated and it appears that SVN 1.6
obsoletes it.  But there's a great tidbit in the comments about how merge
works (takes a diff of start vs now).

I am proposing something more like Branch Per Promotion as described in the
codinghorror.com post.

I'm copying in your last comments on the commit thread to try to consolidate
everything.

On 8/6/12 5:43 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>> At Adobe, around release time, you had to get additional approval to check a
>> fix into the branch getting released.
> This is no longer an Adobe project. We can make releases far quicker (in
> theory) to fix any issues that arise if we need to.
Yes, I sure hope we release more often than Adobe did, but I'm reluctant to
get too release happy and get sloppy in what gets released.  I think it will
still be difficult for folks to move to newer versions.  IMO, the important
customers had their own validation processes that took a while and get
nervous quickly when releases have issues.  We (the committers) have to be
the QA team and try to make these releases solid.
> 
>> That's correct.  Maybe I haven't fully absorbed the Apache Way on this, but
>> in my mind, the dev list folks are the first line of defense for our regular
>> users.  That's why I would have us working out of unstable until we think it
>> is stable enough for less adventurous users.
> How does working in another branch achieve that? As far as I can see it's
> exactly the same (but with added complexity).  If most of the work is going on
> in a branch not trunk then the adventurous user will most likely use that
> branch not trunk. Remember everything is public.
That's correct.  The brave and the committers have extra work to do to
protect the masses.

> 
>> On my bug fix days, I would be doing it in the unstable branch.
> So you would delay on purpose needed fixes going into trunk? Am I missing
> something here?
In my experience reviewing patches from the community, fixes often need
'fixing' or will be vetoed.  I'd rather have that traffic in unstable than
in trunk.

> 
>> The Flex 5 components landed in Carol's whiteboard and eventually she will
>> move them to unstable
> Personally I would of put the completed components straight into the unstable
> branch. You are more likely to get other committers to review and help out
> there.
They will be moved when Carol re-enables some mustella tests for them and
otherwise feels they are ready for more eyes.  This is our first attempt at
donating a large patch, effectively a merge from another repo.

> 
>> Because the bug fix might have downstream issues.
> It may have, but most often not having the fix is worse. Any issue can be
> fixed or reverted if needed there's no need to be commit shy. We are not
> building a product that only get released once every year :-)
I think we have different experiences and philosophies here and will
probably never agree.  But my experience with the SDK is that we have so
many different types of customers that cannot keep up on the latest that
having really good releases is very important.  It is one of the things I
like most about Apache.  We can release when the code is good, not to meet
some revenue deadline.  I might use your approach when providing
applications to clients as you can more easily manage the upgrade.

> 
>> In your experience did you make a branch or otherwise limit access just
>> before a release?
> I've done both and also continued working in trunk. In my experience "code
> freezes" or "branch freezes" meant more bugs get into production not fewer.
> Continue working in trunk has caused the least number of issues for me.
Can you explain why the freezed caused more issues?
> 
>> I don't see CI being good enough given our testing infrastructure
> Which can be improved especially now we have the full set of Mustella tests.
It can't, but I'm not sure we'll get there in time for the next release or
two.  But I'd love to be wrong there.
> 
>>  and I hope we release often enough that there are fewer merge issues because
>> the
>> two branches don't stray that far apart.
> I'm an experienced SVN user and I had several issues trying to merge the
> changes from the patches branch back into trunk. I know quite a few committers
> here don't have extensive experience with SVN and in particular branching.
I don't think you can use the patches merge as typical.  The patches branch
happened before some significant structural changes to meet Apache release
requirements.  Hopefully we won't get that far astray again.
> 
> Thanks,
> Justin




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

Re: SVN and issues with branching / consider how we use SVN going forward

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

Hi,

JFYI there may be less issue with more recent versions of SVN and branching.

In that you can keep branches up to date like so:
svn merge pathtotrunk

And then merging via:
svn merge --reintegrate pathtobranch

Any tired this? How does it work in practise?

Thanks,
Justin