Well, it was all about time. We had one primary db for development and initial testing, a second db for more substantial testing. At times that seemed like too many, added the step of having to do a diff between the two to see what needed to be added to the other db. The VB code base was versioned in VSS, so it was only procs (and the occasional schema change!). Creating more db's would have created more admin work...that maybe we could have automated, maybe not. Not sure that it would have helped us.
For the part, yes, if the change consisted of adding more params, you could add to it. In my mind thats just a different form of versioning, since based on the presence of a value you might then branch to a different bit of code. In some cases it would make sense, but not all - what about when you want to drop params or change the data types? We wanted one simple system with as few exceptions as possible.
On the modifying part, we rarely had to broadcast anything because normally we were modifying code that was in our "segment". In the case where we needed to cross the line, a quick email (or just yell, since we had three offices in a row). One nice part is that we only altered non-deployed procs, so if the worst happenend and all three of us tried to version the same proc, two would get errors saying the proc already existed - a clue that something was wrong! The rule was if you modify the calling syntax of the proc, you search and fix ALL references to it, in code or in other procs.
Yep, we've got a few versions. At some point I'll clean them up, but for now what does it hurt? The worst case so far is one proc has 10 versions, two that never got deployed.
Which is the current version? Normal practice would be that the highest number would be live, unless it had an 'xx' appended denoting it was created then never deployed. With a small team that worked well. If you had a doubt, a quick search of the source code would show which was called (and if none, that would indicate it was a sub proc, though the comment should have told you that).
Your idea of the files isnt much different than what Steve Jones does, and possibly its a better solution. I certainly find VSS to be totally workable for VB source code, there if I want to change something I do, knowing that I have the ability to roll back to any point. I do use VSS for some special procs (outside of this project).
I guess finally, keep in mind two things. One is that we had a team of three developers of about equal ability and all reasonably detail minded. The other is that we were essentially working on a development server, not production (though we lived on the wild side and had everything on one box).
I dont disagree with any of your points, a full source code implementation would be the right approach. This was just a hack to carry us through. While definitely we want to look at "better" approaches for future projects, for the short term I'd use this again in a minute:-)
I appreciate you taking the time to add your comments - pretty important for anyone reading the article to have a very clear idea of the pros and cons of this method and a good discussion is a great way to do that!