Automatic $VERSION updates and subversion tips?

[bsb]

I'm looking ways to manage $VERSION numbers automatically. I used to use the CVS Revision keyword to fill the version. As I now use svn and svk, a new trick is required.

The most useful thing we've found so far is an E::MM::FAQ example although there's probably more out there (googling subversion, perl and version is a mess). This quote explains some issues with svn and svk:

In SVN, $Revision$ should be the same for every file in the project so they would all have the same $VERSION. CVS and RCS have a different $Revision$ per file so each file will have a differnt $VERSION. Distributed version control systems, such as SVK, may have a different $Revision$ based on who checks out the file leading to a different $VERSION on each machine! Finally, some distributed version control systems, such as darcs, have no concept of revision number at all.

The CVS incantation I used to use was:

 # CVS exmample
 $VERSION = sprintf "%d.%03d", q$Revision: 1.1 $ =~ /(\d+)/g;

Subversion has keyword substitution but, as mentioned above, it's handled differently to cvs.

What tips do you have a automatically managing version?
What about using $Date$ for versions? eg. 2008.02_18
Is the PBP "use version; qv()" actually a BP?
How are branches best handled?
Are there other ways to update versions, not using the source control system?
Is the attempt to do this automatically flawed?

Thanks,
Brad

[kyle]

I asked this question a while back: Best Practice for automatic version numbers? You can see the answers I got there.

I wound up taking out the automatic version numbers I'd had before. I wasn't using them for anything anyway, and supporting them under the new RCS (git, in my case) probably would have involved writing commit hooks or something.

[proceng]

In SVN, $Revision$ should be the same for every file in the project so they would all have the same $VERSION.

This falls apart when you use helper modules/libraries. In order to maintain these files across projects, you need separate copies (which will quickly get out of sync).

Distributed version control systems, such as SVK, may have a different $Revision$ based on who checks out the file leading to a different $VERSION on each machine!

This is more a management problem than a technical one. Team members should follow a procedure where builds are only done after checking out updates (if individual modules are used as opposed to a "library" type file that is linked to).

Finally, some distributed version control systems, such as darcs, have no concept of revision number at all.

If there is "no concept of revision number", this is not strictly a version control system (IMHO).

What tips do you have a automatically managing version?

Choose one system and use it across all projects. When you use multiple ways of tracking changes, some will get lost in the shuffle (think Murphy and his friends).

What about using $Date$ for versions? eg. 2008.02_18

This works, if a master list is maintained of what changes are made and in what order.
The major strength of a revision control system is the ability to revert changes to a known point. This is why most will only allow a module to be checked out for update by one person.
When a date variable is used to denote revisions, this can make it difficult to manage a multi-tree project (ie: development, test, production). It also makes it difficult to distinguish between major versions (ie: text mode, GUI, client/server). While ideally the back end should not matter, this is rarely the case.

Above all, remember:

In theory there is no difference between theory and practice. In practice there is. (attributed to multiple people with slight variations)

Good luck with your project.

[tilly]

Finally, some distributed version control systems, such as darcs, have no concept of revision number at all.

If there is "no concept of revision number", this is not strictly a version control system (IMHO).

Thereby demonstrating that your opinion is somewhat uninformed.

Note the original poster's comment was about distributed version control systems. In short they are version control systems whose purpose is to allow multiple source trees to grow in parallel while regularly passing patches between them. In this situation there is no central repository, and with no central repository there is no central notion of a revision number.

This in no way limits these systems from maintaining all of the essentials of a version control system. Such as an annotated history, the ability to reproduce the state of a file at any point, the ability to review each historical patch, the ability to tag a tree and the ability to generate a source tree that is the same as the version that was tagged.

The major strength of a revision control system is the ability to revert changes to a known point. This is why most will only allow a module to be checked out for update by one person.

If I had any doubts about how poorly-informed your opinion is, they would have just gotten resolved. Go off and learn what CVS showed the world about source control back in the 1980s. Once you've seen it work, well, I would outright refuse to work for a company that used a source control mechanism centered on locking access to files when people are working on it. Because if a company has that poor of a clue about effective source control, what other basic ideas are they missing? (Plus I don't appreciate my employer wasting my time like that.)

[tilly]

As long as your source code is kept in a single tree, Subversion's $Revision$ works perfectly well. The only thing you need to do differently than in CVS is that revision numbers are integers. So you get something like this (untested) code:

# Subversion example
($VERSION) = (q$Revision: 123 $ =~ /(\d+)/);

For the record, that is what I do at $work.

As noted in the link you were dealing with, if you're using a distributed source control system, then you run into problems with different people having different versions. The cheap solution to that is to define one version as canonical, and have that version use revision control to produce version numbers. So you can have a script which runs on that system that, after you take patches, uses its revision number to set the appropriate $VERSION and then produces a patch for everyone else. As long as only one machine generates $VERSION patches, you shouldn't have too many annoying conflicts to resolve.

[bsb]

I usually develop with svk connected to an svn mirror and deploy from an svn build environment, so I can probably just use the svn revision number as the master version. I may occasionally need to use svn to checkout a specific version, but that's a rare occurrence.

Thanks