This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Keeping Your Versions In a Line
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
Do you like your versions forked or branched?
I will not, cannot, have them forked.
I do not, will not, like them branched.
I am sad, not glad, the graph is horked.
We can do this, yes we can.
There is a way, we have a plan
We'll keep them versions in a line!
Now your graph, it looks just fine.
Take package Yutz. You're working on it. Sometimes, so does your friend BillyBob. Yesterday, you loaded up the most recent version of Yutz (version 59), and started refactoring the Yutz package's support of gummi bear blending. In the mean time, BillyBob loaded 59, and has been happily pounding away at the new bales-n-targeting eye candy. He's a code demon, he finished last night, and published version 60.
Happy that your testGlummiBearBlending tests now pass, you're ready to publish. You hit the publish button. What!?? It wants you to publish version 59.1. You could publish. Then merge. Then publish again. Each time this happens of course, your nifty version graph shown by the excellent tools provided by RBStoreExtensions draw something that looks more and more like a fractal equation.
Or you could keep the version line straight. This after all wasn't really a legitimate "branch". It's not like you "forked" the project to go in two totally different directions. You just need a way of serializing your otherwise parallel development efforts.
First we save your image. This way, if you don't trust Store, you've got a back up. Isn't that better than littering the repository with intermediate versions?
Second, go to the package version graph, scroll to the end, get the menu for version 60 (BillyBob's latest version), and select merge into image. Up pops the list. Many claim this list confuses or scares them. I've never had real problems with it. I pick the ones with the open boxes (when there are any -- if there are lots, you've got other problems), and choose the resolution. I guess, I just trust the thing, and it's worked out.
Third, select the File/apply resolved and close the merge list window. It's gonna complain that you didn't publish the merged stuff. Duh! Isn't that what we're trying to do here? We'll get it. IOW, ignore the warning, select Yes.
Fourth (this is the not-so-obvious part), select package Yutz in the RB's package list, and get the menu option Versions/Reconcile With Database. Up pops a warning. Again with the "duh!". We know what we're doing; select Yes. When the list selection dialog of all Yutz versions opens, select version 60 of Yutz.
Fifth, publish your package. It'll default to version 61. And your graph will stay nice and straight. And your code repository has real "units of work" in it now.
Previous Topic
