Subversion

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.