Change management is a superset of the old concept of version control.   The repository servers in CVSNT Server and CM Server are fundamentally different from simple version control servers - they understand change sets, and the CVS Suite and CM Suite packages provide a variety of change management features.   You can still work the old way with simple versions, but CM analysts have found that many of the benefits attributed to SCCM only come through the use of change sets.   Buy now for £85.

Versions

A version is typically represented by a number (eg: revision 10, or version 1.6) and has properties like a date, author etc.   Versions for each file may be the same or different, they may be short or long, so most commonly people refer to a label rather than a version (eg: RELEASE_2_5).

Limitations of versions

Versions track changes to files over time, but they have no business meaning.   The label attempts to put a business meaning on it, but it's an artificial construct.   In the above example: RELEASE_2_5 contains the bug fix 11232 and 11233; RELEASE_2_6 contains bug fix 11232, 11233, and 11234. But what label do we use if we want a release to contain bug fix 11233, and 11234 but not 11232?   There is no such label.   This is why we say the label is an artificial construct - it's not an intrinsic part of the business process, it's merely a sticker applied after the fact to make sense of this sequence of revision numbers.

Different types of Change Sets

Modern versioning systems often support change sets, but not all change sets are equal.   The most common type of change set is an atomic changeset: this relates together all the files checked-in at one time. An atomic changeset is useful if you need to rollback after a power failure or error.   CVS Suite and CM Suite create atomic changesets with every check-in automatically.   You can identify any check-in, or rollback any check-in using the commitid.

A user defined changeset: relates together different files, checked-in over a period of time, by many different people (or only one person).   These user defined changeset are especially useful for relating versions to work: jobs, bugs, customer requests etc.   You can create a user defined change set from any of the CVS Suite tools, and non-Suite tools like Eclipse by just putting in a bug number in the message.   If you have the server integration to Jira, Bugzilla or Mantis enabled then the bug will be automatically checked based on the rules you have defined (eg: bug exists, bug is in the correct state, bug is assigned to you, etc.).

Test/Release fixes & jobs

Because the underlying repository understands which changes were made for different items of work (eg: bug fixes, or features), you can promote the changes to the QA environment or Release instead of promoting a point in time with a label.   So in the example on the left: it is not version 1.6 that is promoted to testing, but change set 11234 - the difference between version 1.4 and 1.6.   The release label/tag RELEASE_2_5 can still be created later to refer to the sum of all the changesets promoted.

Each changeset only contains the changes that were made as a part of that work.

Eg: in this simple example the fields selected were a part of 11232, the date condition was a part of 11233 and the ordering sequence was part of 11234.

So if RELEASE_2_6 contains 11233, and 11234 but not 11232 then it has the date condition and the ordering sequence only.

Change sets are not compulsory

If your project doesn't have any units of work, and you just need to promote the latest version of a file or project, you can still do that too. You can use a mixture of changesets and label/point-in-time release procedures or promoting.

Change sets can be rolled together

You can combine multiple change sets into a single change set during promote.   For instance it is very common to create a rollup but in Bugzilla to track all the bugs fixed in a service release. Each bug is made dependant to the rollup and when the changesets are all merged onto the testing level they are all committed using the new SP-1 bug id.

More than just a link to Defects

Change sets are more than a simple link to a defect in a separate tool. Your versions and what you want to do with them: test, release, audit, reuse - are all intertwined with the reason why the work was done. Programmers may get some benefit out of seeing the history of changes to source code, but they get much more benefit from seeing each change, and the reasons why those changes were made: the functional spec, the customer request, the test plan cases, the press releases.

Some companies attempt to implement change sets by taking a verison control tool and simply integrating it to a defect tracking system.   That gives the defect tracking system lots of information, but makes it difficult for people using the files as a starting point.   With CVS Suite and CM Suite you can use change sets to dramatically improve your return on investment from SCCM.