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
