This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Store Matters
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Over on Rich's blog, there's been a comment thread vis-a-vis a Store. I thought I'd surface the issue here for further conversation - I'll do that by bringing up a few of Reinout's questions and answering them as best as I can:
First, I said that we would be shipping support for configurations. Reinout responds:
Too late for the shop where I work, we are already up-and-running with lineups as implemented by Cees de Groot. Why should we switch to Store config maps?
It's a fair question, and we are late to the party with this. Having said that, here's the answer - sure, you can stay with your solution - and it will probably be more specific to your needs than a general solution that we come up with. On the other hand, you end up supporting it, instead of having us do that. That's a non-zero cost that may matter someday. YMMV of course, but there it is.
Next, I brought up optimization - we haven't done a great job with indexing in all cases, and we issue a number of queries at points that don't work well over slower links. These are things we know about, and intend to fix. For that matter, we are highly motivated to fix these sorts of problems - our engineering team is highly distributed, and runs into this problem all the time. It's gotten better, and will continue to get better.
Next, Reinout lays out a problem:
Select three packages.
Imagine that these three packages' changes constitute a rename of one single class.
Imagine one other person and a staging-bot simultanously publishing one of those packages, imagine three build-bots each busy building some image configuration containing these three packages.
Now pull down and select the 'publish' menu item.
I may be off here, but this seems mostly like a process issue. I consulted at a big Envy shop a few years ago, and they had this same exact problem - it's hardly unique to Store. If multiple people are fighting to publish the same package at the same time, then - IMHO - you have a process issue on your hands. What should the tools do here? At present, you'll get multiple forked versions that need to be merged - just like in any other source toolset I know of. I need to know what the proposed solution to this is...
Finally, there's this
Committing is "saving", a set of changes. I can roll back to any revision of these changes provided I remember its address (or UID, whatever). A revision carries its history. Publishing is asigning a version number and making the changes visible to other developers.
I don't get this. I rollback changes all the time in Store - loading previous versions, or even just previous versions of methods (I spent all day doing this with BottomFeeder today). I'm not following the problem here. Which isn't to say that there isn't one - I'm just not getting what is being asked yet.
Previous Topic
