Page 2 of 2

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 9:01 am
by Jenk
No.. a release branch is a snapshot. It is never modified after it has been copied from trunk. Modifications only occur on trunk.

If there is a reason for a new deployment or release, we take a new snapshot and release it - by copying to a new release branch, which gives it a release/version number, and also a read only (ergo 'safe from further modification') branch.

This has the added benefit of being able to use svn diff to identify the differences between version 'x' and version 'y' so that we can update, or rollback deployed versions should they be necessary.

It is *entirely* different from using development/bug/working-copy branches.

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 9:15 am
by Eran
So I still don't understand - if you have a feature under development that isn't ready for production - it is simply incomplete. You say you put it in the trunk. How can you roll out critical bug-fix now? where do you apply the fixes, and deploy to production?

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 9:25 am
by Jenk
If something is committed to trunk and it is broken code, trunk will get reverted, and the developer responsible will have questions to answer.

What "features" are you talking about? There is nothing that can't be broken down into small constituent parts that are added like piece meal to trunk.

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 9:42 am
by Eran
Of course there is. For example, I am currently developing an application platform (http://www.octabox.com). For each mini-application I develop (such as a task-list, calendar etc.) I create a separate branch and work on it until it is ready to be deployed in production - until then there are incomplete layouts, incomplete functionality and so forth in the branch. It's not that the code committed is broken - it is simply not finished.

In the mean time I submit bug-fixes constantly to the trunk. When the application is completed, I merge it back into the trunk. The development time for such mini-application can be between 7 to 14 days. It will be unacceptable to release a half-baked mini-application (=feature) into production. It all depends on the scope of the features.

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 10:18 am
by Jenk
Incomplete anything = broken code.

Sounds like you are biting off more than you can chew if you are having all this broken/incomplete code everywhere. Need to break it down further.

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 11:44 am
by panic!
With regards to layout I follow, I guess that's just standard though:

http://svnbook.red-bean.com/en/1.0/ch05s04.html

http://svnbook.red-bean.com/en/1.0/ch04.html

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 2:15 pm
by alex.barylski
I agree with Jenk...standards are great when there are so many to chose from. :lol:

I don't think the standard SVN way would work my situation...

I would have live clients which all use a "standard" well tested snapshot or version, no experments, etc...

However should the client desire a tweak or customization I "should" be able to create a branch for their account and merge changes back and forth between the trunk and account. That is the idea anyways. It's a little more indepth than that.

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 2:35 pm
by Eran
Incomplete anything = broken code.

Sounds like you are biting off more than you can chew if you are having all this broken/incomplete code everywhere. Need to break it down further.
You're talking in mantras that do not correlate to the real world.
It's not "broken/incomplete code" everywhere. A certain, isolated part of the application is currently under development, I don't see how is that so hard to understand. The branch/trunk paradigm was built exactly for this purpose.

Do you complete a 7-10 days development process without a single commit? how do you commit parts of an application that are not ready for consumption though they work independently into a production line? maybe my standards for production-ready are different than yours, but I don't see how is that acceptable in a real-world situation.

Also you need a place to test the features before releasing into production, even when they are ready. They might (probably) require some modifications - this is a process, you develop some functionality, make some changes, develop more - but you don't release unfinished product into a production environment.

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 3:11 pm
by panic!
I agree with pytrin; branch and commit regularly.

SVN can work for any scenario.

Re: Subversoin best practice

Posted: Tue Dec 02, 2008 8:39 pm
by Jenk
pytrin wrote:
Incomplete anything = broken code.

Sounds like you are biting off more than you can chew if you are having all this broken/incomplete code everywhere. Need to break it down further.
You're talking in mantras that do not correlate to the real world.
No, I'm talking agile, Scrum and "Commit Early, Commit Often." I haven't gone into detail because I didn't have time. In your example of a calendar "feature" (another ambiguous term, it's simply additional functionality of an exisiting application) you create the layout of the calendar month/day/year whatever. commit. Create the date fetching/layout population. Commit. Create the 'today' highlighting. commit. Create ability to add appointments/notes/whatever on a day. Commit. Create the front-end/gui to enter those dates. Commit. Create the ability to enter a range of dates. commit. Etc.
It's not "broken/incomplete code" everywhere.
Yes it is. You even said yourself it breaks the build.
A certain, isolated part of the application is currently under development, I don't see how is that so hard to understand. The branch/trunk paradigm was built exactly for this purpose.
It's very easy to understand, it is you who is failing to understand the problem. It is old hat, and only serves to increase development time and the probability that there will be conflicts/collisions when you merge.

Branching serves no purpose other than to keep a safe copy of your working copy, or a collaborated working copy between peers. If it's a collaborated working copy.. what's the point? That's exactly what trunk is.

Pair program, don't pair wc. Use test cases and constantly update from trunk. Do not wait/delay to see if everything breaks on merge a week or two later.. by which time several other branches may be committed, making the original problem/collision n times worse. I'm willing to bet a lot that your developers will talk to each other when using different branches to see if API's will change or what not, maybe have a meeting, draw a few diagrams, send a few emails, make some notes on what changes will be merged in 2 weeks time, make a few mistakes with names, etc.. So why not just commit to trunk and let them see for themselves, and use the new code as soon as it's ready?
Do you complete a 7-10 days development process without a single commit? how do you commit parts of an application that are not ready for consumption though they work independently into a production line? maybe my standards for production-ready are different than yours, but I don't see how is that acceptable in a real-world situation.
Re-read what I said about Releases. Then read it again, and if you still haven't got it, read again. All the info is there. We work on trunk, and create snapshots for releases. We operate 2 week sprints and create a snap shot at the end of those two weeks, everytime, safe that it is 100% working code in trunk. We have automated testing, automated integration (i.e. app builds and runs tests automatically every 5 mins, with the "traffic light system") and of course, no collisons to worry about from delayed commits (which is what branching is.)
Also you need a place to test the features before releasing into production, even when they are ready. They might (probably) require some modifications - this is a process, you develop some functionality, make some changes, develop more - but you don't release unfinished product into a production environment.
We deliver it to the customer and let them tell us what they want changed. We do enough to satisfy the acceptance criteria of a user story and nothing more. To do any more is cheating yourself and the customer. We deploy a version if/when the customer is happy with that version.

As for "branch and commit regularly" you are do nothing for the second if you do the first. All you have done is take a copy of trunk, and it is immediately out of date. All your "regular commits" are then stocked up and done at once when you merge. You are *not* committing regularly if you branch, period.

Re: Subversoin best practice

Posted: Wed Dec 03, 2008 2:08 am
by jmut
My experience. Commit often. Thats the greatest benefit of svn...so that you don't loose work. You can't afford to commit once a week and risk going out of track or lossing work just cause your kid played with the laptop. Agree with Jenk and pytrin there. Branches have their place and can be great asset to software lifecycle but on the other hand if overused they do more harm than help.