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.