Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Keep us updated on your thoughts and usage issues. I recently got turned on to the idea of converting to SVN after being exposed to is in the modperl/Apache::Test dev lists.

    I like the web interface a lot better and getting source through a proxy via http:https rulez, but having a copy of Apache2 around just for it seems like a pain, altough I hear CVSWeb groks SVN now too.

    I still can't get my brain to accept how tagging and branching works without a branch/tag command. :-) The other thing that bugs me sti
    • and getting source through a proxy via http:https rulez, but having a copy of Apache2 around just for it seems like a pain

      You don't need to have Apache2 around to use Subversion, just for the webdav stuff (though Apache2 and mod_perl 2 are nearly mature.) You can set up svnserve (ie. svn: urls) which is the most efficient, its analogous to pserver, with less suck and more security. You can also use svn over ssh ( svn+ssh:) like CVS does.

      There's also a few CVSWeb like things out there. WebSVN [schwern.org] is one. Kinda ugly, though that's a totally stock installation. At least you can get tarballs out of it. SVN::Web is another.

      Personally I use svnserve over an ssh tunnel. Helps to get around stupid coffeehouse firewall rules.

      I still can't get my brain to accept how tagging and branching works without a branch/tag command

      They're just copies. That's it. You're all but literally making a copy of the source tree (they do internal voodoo to make it efficient). However, I have found it quite annoying not having explicit branching and tag commands.

      I haven't used branches in SVN yet and I avoided them in CVS. But I did use tags. The thing to realize about tagging is you don't really need it anymore. Which brings me to my next point...

      The other thing that bugs me still is the revision numbers vs. $Id$ in CVS

      The change in the way revision numbers work is a good thing. Think of it as a project-wide snapshot number. Put another way, a tag for every revision. More to the point, now you know that revision #1234 of Foo.pm goes with revision #1234 of Bar.pm goes with revision #1234 of every other file in the repository.

      Tags are no longer terribly important, you can recreate old repository snapshots without them. They're now just... tags. Names for revisions. Instead of bothering to tag revisions now I just stick a "Version 1.xx" in the log of the last revision before release. Usually adding a timestamp to the Changes file.

      This also means that since every file has the same revision you can use $Revision$ as a project-wide $VERSION in all your .pm files.

      It would be nice if I could do something simple like "svn tag " in my module release script, but its no longer critical for reproducing history as it was in CVS.

      • OK, you've put it another way that makes sense [to me]. I'm installing it now on my dev box. :-) It just so happens I'm working on a new set of modules, so it's a good time to migrate.

        I took a look at your WebSVN. Is it me, or is it slooooooooow?

        Thanks,
        -=Chris
      • This also means that since every file has the same revision you can use $Revision$ as a project-wide $VERSION in all your .pm files.

        I'm presuming that's if you want version numbers of the form 1.49 and so far haven't moved up to 2.0. What do you do if you want to call a release of your module 2.0?

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers