rvosa has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

recently I've started using version control, using Subversion in Win32 (the TortoiseSVN client and the svnserve server). I am very pleased with it and I can't recommend it enough to anyone not using version control. However, I have one question: I've read somewhere, or seen an example, of people using their CVS revision numbers as the last part of their module $VERSION numbers, so that you might have something like 1.02_13 where the _13 is the CVS revision number, which is automatically inserted when making a commit (I think). How might I go about setting that up on Subversion for my code? I supersearched but didn't find what I was looking for, and neither did the svnserve documentation. Do I need the perl bindings for SVN? What do I do?

Thank you very much for any and all replies.
  • Comment on "Subversion" revision numbers as 0.01_blah

Replies are listed 'Best First'.
Re: "Subversion" revision numbers as 0.01_blah
by polettix (Vicar) on Jun 04, 2005 at 16:27 UTC
    You're probably looking for keywords. Keep in mind that you probably have to use single quotes to be on the safe side, because they're using $: 
    my $revision_number = '$Revision$' =~ /.Revision:\s+(\d+)/ ? $1 : '';

    [download]
    You can pepper with some parentheses to make it more readable :) The string will be expanded to something like $Revision: 144 $, at least according to their documentation.

    Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))')

    Don't fool yourself.
[reply]
[d/l]
[select]
      Yay! Yup, that's what I'm doing now. It works. Thank you both.
[reply]
Re: "Subversion" revision numbers as 0.01_blah
by salva (Canon) on Jun 04, 2005 at 16:12 UTC
    You do it the same way as with CVS, the only difference is that some keywords are named different and that you have to tell Subversion with ones you want substituted. It is explained on the subversion book
[reply]
      That's what I needed! Thank you.
[reply]
Re: "Subversion" revision numbers as 0.01_blah
by Fletch (Bishop) on Jun 04, 2005 at 23:33 UTC

    I'd be very wary of using the SVN repository revision as your package's version number. You're conflating a particular state of your repository with a particular public release. Not as automagic, but it might be better to manually retain a more traditional major.minor.patch variable and use svn cp to create a tag in your repository.

    Update: Again, this is IMHO. I haven't maintained anything publicly released with SVN (haven't moved my piddling couple of CPAN modules over to SVN yet), so don't take this as gospel. I'd be interested in hearing more from people who are using SVN in live practice.

    --
    We're looking for people in ATL

[reply]
      I'd be very wary of using the SVN repository revision as your package's version number. You're conflating a particular state of your repository with a particular public release.

      Agree completely. For a start it completely falls down if you maintain more than one module in the repository. Subversion has repository based version numbers so any commit to the repository is going to increment the version number, whether it has anything to do with the module or not.

[reply]
        For a start it completely falls down if you maintain more than one module in the repository.

        Yup, to say nothing of revision bumps created on branches or by creating tags.

        --
        We're looking for people in ATL

[reply]
        Having a common version for all the files on the repository can also be an advantage. For instance, on multifile packages, you don't have to worry about incrementing the version number on the main file every time you change any other one.

        The only real issue is getting used to non consecutive version numbers.

[reply]
Re: "Subversion" revision numbers as 0.01_blah
by adrianh (Chancellor) on Jun 05, 2005 at 00:31 UTC
    However, I have one question: I've read somewhere, or seen an example, of people using their CVS revision numbers as the last part of their module $VERSION numbers, so that you might have something like 1.02_13 where the _13 is the CVS revision number, which is automatically inserted when making a commit (I think).

    If you follow this style you'll have problems releasing modules to CPAN since an "_" in the version string marks it as a developer release.

[reply]
      That was kind of the idea: there'd be "stable" releases without the "_", and developer releases.
[reply]
        That was kind of the idea: there'd be "stable" releases without the "_", and developer releases.

        Ah, okay. Fair enough I guess.

        Personally I'd find it rather confusing since I'd expect a "_42" suffix to mean that this was the forty second developer release, rather than it being the forty second revision of some repository I'm never going to see :-)

[reply]
Re: "Subversion" revision numbers as 0.01_blah
by dragonchild (Archbishop) on Jun 13, 2005 at 01:45 UTC
    I have never used that "feature" when I used CVS, RCS, or when I currently use SVN, nor will I use it when I migrate to SVK in the near future. Release numbering is a completely arbitrary number assigned to a particular state of your application. The only benefit to it is to tell your users what to expect with a new release. major.minor.patch is the only way to go, and those should increment in relation to each other, not to how many commits it took to get to a release.

    This breaks down even further when dealing with something like Pugs that uses TDD, has commits for non-code items (like tests and documentation) ... see what I'm getting at?

    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
[reply]

Back to Seekers of Perl Wisdom