Some colleagues and I are in the process of revising/introducing some Configuration Management best-practices at the company we work for. In particular, we are introducing a new concurrent source control system (Subversion) and we have had a couple of healthy debates come up in regard to what should/shouldn’t get committed to source control.
On one side, we have those with a more purist belief that only the following should be committed to source control:
- Anything necessary to build the project (e.g., source code and any 3rd party libraries that your project makes use of)
- Related objects, such as images or flash files that are required to deploy a website
In another we camp, we have those that believe in using the source control system for more than just source:
- Anything necessary to build the project (e.g., source code and any 3rd party libraries that your project makes use of)
- Related objects, such as images or flash files that are required to deploy a website
- The compiled assemblies at the end of each build
- Related documents (e.g., project timeline, requirements, etc.)
In regard to the first camp, nobody disagrees with the value of having the ability to grab components related to a specific build, at any point in time. For example, if a client asks for release 1.7.9.132, it’s imperative we have the ability to grab that release quickly and that it be identical to the original release (for example, not compiled under a new version of the compiler). Their argument is that committing the compiled assemblies into source control will clutter the repository without adding value. Their preference is to maintain a separate location on a file server, which is designated to storing versioned releases in a hierarchal fashion, on the file system.
The above mentioned concept could easily be implemented by a manual process or a build process that is run on a Continuous Integration server at the time the source is committed to the trunk; however, the less purist camp believes in providing a “one stop shop” for everything.
Another concern of the purist camp is that concurrent version control systems do not lend themselves nicely to working with binary documents (e.g., Word files). For example, to ensure that no two people work on the same binary document, at the same time, document authors must first lock the file before making edits. While this could work, another author may attempt to edit the file at the same time, not realizing the file has been locked (often, an svn commit is required before any subsequent users realize that the file has been locked). This will cause any subsequent user with having to “shelve” their changes and manually merge them, at another time. It is believed that a document control server, such as SharePoint, would better suit document versioning.
For those that have gone down this path, could you please share your words of wisdom?