in reply to Automatic $VERSION updates and subversion tips?

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.
  • Comment on Re: Automatic $VERSION updates and subversion tips?

Replies are listed 'Best First'.
Re^2: Automatic $VERSION updates and subversion tips?
by tilly (Archbishop) on Feb 19, 2008 at 07:05 UTC
    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.)
[reply]

In Section Seekers of Perl Wisdom