Version control

The development team were i work has gone through some changes over the years, new people come in they want the process to look this way or that way. I'm a developer, at the end of the day, the process is just a means to the end, a tool to help me do my job. Other in our team are administrators or quality assurance people - each with their own view and need regarding the process and the version control tool, in this case.

We have for many years been using a version control software called StarTeam. its not free and is probably going to go away in the not too distant future. We have always used it as the central repository for code. Developers work on code, developers check code into repository - thats it. there was not a *consideration of when to check in. The PMO primary method operation was to check in often.

this practice is being called into question, because (imho) we are not able to create a reliable build from the collection. Over the course of time, the tool was not properly used, regarding labels and/or the collection was not used at all - code was placed on the production server that was never commited.

We have used a technique of labeling to create a *build or update that would be used to move code collections (packages) from server a to server b to production. this works pretty well and has been in place for a long time. Once files were distributed to production, the label that was attached is removed and a *build label called inProduction was attached to the files. This build label should produce a reliable mirror of the production server. Our problem is that it is not so we have no way to *recover from a production error.

Perhaps i should create a new branch in ST and move what i think is needed to produce a reliable build into that branch and then use it to build my new virtual production server on my laptop. Interesting possibility.

if we could create this branch and use that brange *moving forward - leaving all the old behind and only bringing in the tip into the branch- and then follow the move conservative pattern of checking in only after you have verified on your local production server - does that solve the problem.