Skip to content

rougecardinal/vclog

 
 

Repository files navigation

VCLog

DESCRIPTION

VCLog is a versitle cross-VCS/SCM changelog generator. It currently supports Git, Hg and (limited) Subversion.

SYNOPSIS

Creating Changelogs

The default output is a ANSI colored GNU-like changelog. From a repository’s root directory try:

$ vclog

The is the same as specifying ‘changelog’ or ‘log’.

$ vclog log

To generate an a different format use -f:

$ vclog -f xml

Creating Release Histories

To get a release history specify ‘history’ or ‘release’ as the subcommand.

$ vclog history

Again the default format is a ANSI colored GNU-like text style.

Unlike Changelogs, Histories group changes by tags. The tag message is used as the release note. If the underlying SCM doesn’t support tag messages that the last commit message before the tag is used.

See ‘vclog help’ for more options.

Bumping Versions

VCLog can also be used to intelligently bump versions. To see the current tag version:

$ vclog version
1.1.0

To see the next reasonable version based on current changes:

$ vclog bump
1.2.0

VCLog can determine the appropriate version based on commit level. Any commit with a level greater than 1 will bump the major number, while any commit with a level of 0 or 1 will bump the minor number. All lower level only bump the patch level.

Writing Heuristics

In your projects .vclog/rules.rb or .config/vclog/rules.rb file, you can create rules for labeling commit messages bassed on commit message.

on /updated? (README|VERSION|MANIFEST)/ do
  :admin
end

These rules can also “massage” the commit message for output.

on /^admin:/ do |matchdata|
  [:admin, matchdate.post_match]
end

Labels are used to categorize and assign levels to commits. Use #set in the rules.rb to specify the level and description of a commit label.

set :admin, -2, "Administrative Adjustment"

NOTE ABOUT SUBVSERION

Because Subversion is a centralized version control system, it contacts the server every time ‘svn log’ is run. For this reason, having vclog generate a release history is likely to fail since it must run ‘svn log’ for each tag. Any repository with more than a few tags may be denied access by the server for making too many rapid requests. I have no idea how to remedy this issue. If you have any ideas please let me know.

RELEASE NOTES

Please see HISTORY file.

COPYRIGHTS

Copyright © 2009 Thomas Sawyer

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.