incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: SVN and issues with branching / consider how we use SVN going forward
Date Tue, 07 Aug 2012 08:04:49 GMT
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


Mime
View raw message