We are making a move away from a long standing version control product called Starteam. Im blogging my learning about SVN along the way.
First - when thinking in terms of SVN or Subversion, think in terms of updating and committing. These are the two primary ways that a developer interacts with the repository.
When a developler updates their local trunk or directory structure, changes from the central repository are automatically merged into the developers local trunk, cool huh?
With our old product, this was not the way it worked. We would deal with files and labels - it would not automatically do the merge. with SVN, the developer need to simply update from the parent collection to their child collection and any changes will automatically come in. If the developer who is updating their collection has made changes to a file that the parent collection is trying to update, then a conflict occurs and the developer must seek out the developer of the last committ to the collection and decide whos change stays.
The concept of checking files into the repository is gone. Now we think in terms of the entire collection - when we update the main collection, we are committing and creating a new version of the entire repository.
If our updates include deleting files and adding new files, we mark those files in our collection with a Add or Delete command and upon the next committ, the main repository is updated. This means that if developer A deletes files and does a committ, then developer B, upon the next update will lose those files from their local collection.
SVN has this concept of an atomic committ process. this means if any problem occurs during a committ, like with the network, the entire process of committ will fail. This means you never have half or part of a committ in the central repository, only a full committ is possible. Revisions are are result of successful committs - aka changeset. By grouping changes to single files in a revision, developers can better track changes as a whole.
Friday, January 9, 2009
Wednesday, January 7, 2009
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.
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.
Subscribe to:
Posts (Atom)