On 8/6/12 8:38 PM, "Justin Mclean" <jus...@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" <jus...@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
