Support Wikipedia

CVS Keyword $Log Can Create Tricky Issues

CVS provides the $Log keyword that you can embed in your source code, typically in a comment section. When you commit your source file, CVS expands this keyword to contain the cumulative commit messages. This way, you can have a record of all the changes to your file documented within the file so you can easily browse them as you are editing or reviewing your code.

While this works well in most situations, it does have its limitations. As well documented, CVS does not handle the expanded $Log text when you are trying to merge a branch version of a file to the trunk. In two of the projects that I worked on, we used CVS branches to provide us a way to maintain a release version for a few weeks, while the trunk was in active development. When we eventually started merging the branch versions to the trunk, we were in for a few surprises.

CVS generally merges versions from a branch to the trunk, or the other way around, except for the log text expanded from the $Log keyword. In almost every case, the log texts from the branch and the trunk result in a conflict that needs to be handled manually. Imagine a project with hundreds or thousands of source files that have $Log embedded. While merging a branch to the trunk in such a project, you would practically end up resolving each conflict by hand!

Another scenario where I ran into issues due to the $Log expansion is probably much less common. I am working on a project where we have separate repositories for development and for the release. Every time we have to make a release, we check out files from the development repository and check them into the release repository. This is done by checking out a sandbox of both the repositories, copying files from the development sandbox to the release sandbox, and running “cvs commit” on the release repository. One would expect only the files that have been modified since the last release to get checked in, and the rest ignored.

But to my surprise, I found that many files were getting checked into the release repository, even though only a handful had been modified. On close examination, I found that all the files that were getting checked in every time we made a release were the ones that had the $Log keyword. Because of the way this keyword expands every time it gets checked into the release repository, it will always look different from the file copied from the development sandbox, even though it had not been modified. The log text will have the commit message from the check in to the release repository, that will be missing in the development version of the file.

To work around this problem, I would have to either remove the $Log keywords from every file that has it, or develop some sort of a filter. Changing the string “$Log” to something else while copying the files from the development repository to the release repository would be another way.

In any case, $Log tends to cause problems when you least expect it to. This keyword expands to the same text as you would get when you run the “cvs log” command, so it might just be a good idea to not embed this keyword in your source files.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>