VCS - Branching or not?

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

VCS - Branching or not?

Post by Jenk »

[Moderator note: Split from viewtopic.php?f=6&t=107862]

We don't branch anymore (our own study, as well as other's, showed that branching is a waste of time) :) nor do we use a bug-tracker (bug is in fact a prohibited word!)

What other benefits does Mylyn have? I notice it has ties to subversive in Eclipse, but I've not installed it (I do use Subversive though)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Mylyn

Post by josh »

Jenk wrote:We don't branch anymore (our own study, as well as other's, showed that branching is a waste of time) :)
Can you elaborate or link? I can think of two scenarios right off the bat:
- creating separate "editions" of the product that involve cross cutting concerns ( not as simple as including/excluding the module)
- fixing 'issues' in previously released software before releasing functionality under development

Are you saying you can implement a feature however complex, without committing any changes you would not be comfortable with in production? So what if you wanted to prototype a page before writing the real "guts" of that page, you would just not do any commits until it was done? What if it was going to take a week and you needed to maintain that file?

But yeah the subversion integration was huge. Unfortunately I couldn't get the DBG extension for eclipse to work.

I need to be able to put debugBreak() calls and debug ajax events that way, does anyone know if this is possible in eclipse? Right now I am using phpED but its got a lot of bugs and short comings, its worked good for me for a year though but seeing some of the stuff eclipse offers makes me want to switch. IDE developers are stupid, all the little "time saving" stuff backfires on you. I am impressed by eclipses' plugin community though, it looks like they have a solution for every IDE problem I've had. Except I can't get over this debugger hurdle. Without integrated debugging I can't use mylyn :-(
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Mylyn

Post by Jenk »

Branching, and committing to a branch, is a fallacy. You're simply delaying all those commits until you have to merge back to baseline.

Prototyping is also a development fallacy. There is no such thing as a prototype, only lazy development (i.e. not bothering to employ tests at the start) no body "throws away" what they first work on, so why not have it in a test harness from day one? You've then got tests to prove it (the app) won't break. We don't make models (e.g. motoring industry) as proof of concept, we don't do wind tunnel testing with 1:10 frames, etc. We produce software, and refactor it until it fits requirements.

Commit early, and commit often. Every time there is a green light on your tests, commit.

(When in a team) Paired/Peered programming - you're not a one man show committing a load of changes, there has been 2 (or more) of you working on the same code, so it has been reviewed as it is written. Tests/Specs also count as reviews, i.e. you have proof it works, you do not need a second opinion. :)

One 'branch' (i.e. trunk) with frequent updates is much, much easier to manage. No cross-branch maintenance required, because there are no branches.

Progression continues on one branch, it is delayed when spread across multiples. No "chunk" updates (in the form of branch merging) and no show stopping conflicts - ever - because of differences in branches (again, there can't be any differences between branches, because there are no branches! :))

Conflicts are kept to a minimum. This doesn't only mean conflicts can/are reduced by number, but also by complexity. When everyone is working from the same branch and frequently updating/committing, conflicts are usually nothing more than a few includes or name changes. When we used to have multiple branches, we'd find entire modules could conflict because of two branches differing changes to a shared module or similar.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Mylyn

Post by josh »

Jenk wrote:
Prototyping is also a development fallacy. There is no such thing as a prototype, only lazy development (i.e. not bothering to employ tests at the start) no body "throws away" what they first work on, so why not have it in a test harness from day one? You've then got tests to prove it (the app) won't break. We don't make models (e.g. motoring industry) as proof of concept, we don't do wind tunnel testing with 1:10 frames, etc. We produce software, and refactor it until it fits requirements.
Yeah but when an Engineer is working on the '10 model of the new car, he would not expect his boss to come and take the designs and ship them with '09 model. Also I think total rejection of branching would not work because bugs in previously released software do happen and do need to be fixed. Do you have any of those "studies" you mentioned though, or is this just your opinion (no offense)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Mylyn

Post by Jenk »

We do create release branches, though we call them snapshots and they are read only. If the client wants something to be fixed, then they must update (there is no cost implication on this.)

I can google "Commit Early, Commit Often" for you, if you really wish, but I'd rather you did dispute the claims I am posting before demanding other sources (which are only going to be other people's experiences and opinions anyway...)

As for your boss "taking the '10 designs and shipping with the '09 model", I'm not sure I follow. :)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Mylyn

Post by josh »

I have various plugins and libraries I work on, the other week I wanted to integrate a 1,000 line jquery class into my Magento extension, it had to be overriden in some points to talk with the ajax script the way I needed though, so I branched, while I worked on that paying customers said I'll buy if you add xyz feature, so I added it on another feature branch and re-integrated, then re-integrated my jquery plugin when I was done, I got all the business and didn't have any major issues re-integrating. I think it is a tool, for example if you're going to change an interface do it on major version not a minor release, only small changes

I mean if you don't have ANY bugs or mistakes, and you are able to add all features at all times without commiting unstable changes, I'm glad, but me personally, if something is going to take a week I might need to check in every few hours, even if the code doesn't even compile, if its in a branch I know I'm safe though.

I wasn't trying to get you to google anything for me, I was searching for branching pitfalls, branching criticism, etc.. and couldn't find anything. I don't think branching is inherently a bad idea, there are just some "anti patterns"
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Mylyn

Post by Jenk »

We strictly operate on a "don't commit broken code" basis. We simply must have very strong test coverage for this, we also have a continuous integration server that every time someone commits, will start a build and a test run. If something fails, everyone stops development and fixes it. Everyone that uses that repository/code base. We are also able to identify what broke it, because each commit is associated with a build.

We attended a TDD seminar last night, and it just so happens that this topic came up for a brief moment, as they also discussed continuous integration, which is not possible with branching.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Mylyn

Post by josh »

So lets say you integrating a 1,000 line jquery file to talk to a different ajax API then it was originally developed against,
assume this is more then a days work, you want to start right away to bring more clients on board... great

Halfway thru you get a bug report for your deployed software, do you just revert your changes so far? Create a second working copy? Wouldn't having 2 working copies with different changes in each one, just be branching without commiting and how is it different?

If you check out a past release and fix a bug, while you also have another working copy with uncommitted changes, how is that different then branching (other then the fact that your changes in process aren't backed up anywhere or versioned, allowing you to screw up your own code?)

I just started branching, I was having lots of problems that it seems to be solving. What should I be doing differently? I write tests and try to commit small changes, but sometimes changes can take days. If I want to check in my changes along the way, I don't see how it would shoot myself in the foot, as long as I make sure to re-integrate before refactoring?'

I'm interested in your suggestions here, because either branching solved my problem, or I was doing something wrong to cause this problem in the first place.

Anytime you have 2 working copies (different developers for example) there is always opportunity for conflict right? As long as everyone re-integrates daily shouldn't they be allowed to make branches, just to make sure they don't accidentally fubar their days worth of changes before committing?


And also just because you have unit tests on a class that means the user interface for that module is ready to be deployed if someone builds on the HEAD revision? Shouldn't things be branched at least until the user interface is working in a way that is acceptable to go live? Passing unit tests, and ready for users to use are two totally different things. I know for a fact its impossible to write tests so good you catch all bugs, even NASA has bugs, every conditional you use multiplies the possible execution paths until you get complexity explosion, so automated testing alone will not be enough. How do you make urgent builds to the software if there is changes that are untested
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Mylyn

Post by Jenk »

We do not do multiple check-outs, that is pointless, even if from branches.

If a bug is reported, we add it to the backlog/product queue of things to be worked on, and in due course it will get worked on. If it is deemed that important, all current work is ceased and the bug fixed, then work resumes (usually means restarts.)

Once software has been released, it has been released. It is completely illogical to release software but resume work on it. If clients want the bug fixed, they must update. If it's that bad a bug, there will be no charge to do so. They accepted the software in its current state, i.e. including the bug. We do not do maintenance releases, it is doing nothing but multiplying the amount of work to be done.

The point about multiple branches/working copies is that it allows time for differences between branches to substantiate and become problems. Removing branches, and minimising the time between commits (and updates, everyone must update before committing) reduces this chance for conflicts, because they are small (yet to substantiate), usually merge fine, and most importantly easily manageable. The ideal would be everyone works from the same copy, but that is impossible, so we have the next best thing: Everyone works from trunk, everyone (very) frequently updates/commits.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Mylyn

Post by josh »

I meant multiple checkouts, 1 checkout per developer, isnt there is still going to be conflict regardless when the code is integrated regardless of wether or not the developer checked his work into a branch before the trunk?

Do you find that with this methodology there is stuff that comes up that you want to change but can't because of backwards compatibility? That is one thing branching helps with, like if I am changing an API that has calls scattered throughout the application, sometimes its easier to make a branch so it doesnt interrupt the whole development, I would like to know how you deal with this kind of stuff. If the guy updating all those method calls doesnt check in for a few days, there is just as much room for conflict as there is had he created a branch, is there not? (the only difference in that context is the rest of the team gets to see his branch before it is finished, so they know what changes are ahead?)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Mylyn

Post by Jenk »

I'm aware you meant multiple checkouts, hence my response about multiple checkouts. Everyone updates and commits very often (hourly, if not sooner) to minimise conflicts.

We all do paired or peered programming anyway (peered meaning more than two) so the number of checkouts is always less than that of developers.

We don't have issues with backward compatibility. We have methods for dealing with those, such as decorating the new API or just by simply refactoring that which is broken. There's very little chance of an API change in a library causing a horrific breakage anyway, nothing that a quick run of tests and perhaps and hour to fix can't solve anyway.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Mylyn

Post by josh »

Ok so let's say your boss says, add the ability for us to have this screen that is a 3 page form that has all these custom fields that have to be developed, etc.. Let's say it was 2 weeks work...

You guys would create that screen with only 1 field to start, and actually check that in? Then what happens if there is an urgent bug and all development stops as you say

when that bug gets fixed, this new module with it's 1 measly field actually gets deployed for the users to see "unfinished" (even though that 1 field is unit tested)? I don't see how you avoid pushing features in their infancy without putting them on a branch (if you really do check in every 2hrs).

Wouldn't your "boss"/"client" or w/e ask you why the hell you thought you would do a build of the module without the other 50 fields finished?
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Mylyn

Post by Jenk »

That's a poor example, because it wouldn't be just one field.. it would be the entire form, as a collection of input values.

But regardless, that is of no relevance as we work in Sprints, and we have release planning. If there is an emergency, the sprint is terminated/aborted and we fix the emergency, then plan the next sprint (which will continue with the stories left out from the terminated/aborted sprint) this emergency work also includes time to remove/rollback unfinished features.

If the boss or client walks in and demands a rollout/deployment and we aren't ready for one, we'll tell him/her so. The rollout plan will also include time to rollback.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Mylyn

Post by josh »

Jenk wrote:That's a poor example, because it wouldn't be just one field.. it would be the entire form, as a collection of input values.
Well, ideally... but lets say it was more than 2 hours of work. Do the changes get committed in progress?
Jenk wrote:If there is an emergency, the sprint is terminated/aborted and we fix the emergency, then plan the next sprint (which will continue with the stories left out from the terminated/aborted sprint) this emergency work also includes time to remove/rollback unfinished features.
So you just completely revert all work in progress, if there was a bug in a release from a month ago? What if you had 100 man hours in so far on the trunk. Do you think it would take more than 100 man hours to go back to a release branch, make the fix there and then merge it into the trunk? (rather then throw out the 100 man hours put in so far?)
If the boss or client walks in and demands a rollout/deployment and we aren't ready for one, we'll tell him/her so. The rollout plan will also include time to rollback.
So the disadvantage of this approach would be that the trunk is too volatile to be deployed at any given time? (versus only merging stuff into the trunk once it is approved by QA and all stake holders)?

So one aspect of CI is commit early and commit often, but isn't another aspect supposed to be that you can do daily, hourly builds, instead of weekly or bi-monthly?

I just can't get past the fact that it takes me a certain amount of time to make a change, and that amount of time is sometimes longer than the amount of time I get between having to push updates, somewhere, the way I see it.. I have to separate tested & untested code, at the minimum.. I don't see how you do it

The only way I see to keep the trunk stable like that is to selectively merge in ranges of revisions after stuff is complete (in everyone's opinion, from a product maturity & feature completion standpoint, a usability standpoint, etc... not just because there are a few unit tests on it)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: VCS - Branching or not?

Post by Jenk »

No we don't revert all changes, only those that are unfinished, like in your example - a form without function. In fact it probably wouldn't get reverted, just into a state that would never incur it. I.e. it's in the code, but you can't get to it.

We have a continuous integration server that runs builds and test hourly, and every time someone commits via an SVN hook. Our code is ready to go, any time, it just might have a few odd 'features' that need a quick tidy up ;) The time saved by not branching far, far outweighs the time spent preparing trunk for a release.
Post Reply