Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

Journal of rafael (2125)

Wednesday December 04, 2002
06:33 AM

Subversion / MakeMaker tricks

[ #9262 ]
Want to maintain a Perl module under Subversion ?

If you're using a version of ExtUtils::MakeMaker < 6.06 (which is not
released at the time of this writing), the following steps are necessary :

1. Put a MANIFEST.SKIP file in your top-level directory. It
should contain the line


as well as the other MANIFEST.SKIP standard excluded files :

    # Avoid Makemaker generated and utility files.
    # Avoid temp and backup files.

2. In your Makefile.PL, redefine libscan() :
(see the manpage for ExtUtils::MM_Unix)

    sub MY::libscan {
        my $path = $_[1];
        return '' if $path =~ /\B\.svn\b/;
        return $path;

Other tricks :

Want to have an automatically generated changelog in your distribution
tarball ? Here's how :

        dist => {
            PREOP => 'svn log > ${DISTVNAME}/ChangeLog',

Want to avoid noise when using "svn status" ?
Use this svn command at the root of your source tree :

    $ svn propset svn:ignore 'blib
    pm_to_blib' .
    $ svn commit -m 'Ignore MakeMaker-generated files in svn status' -N .

For a maximized hype, use the following options to WriteMakefile() :

        dist => {
            CI => 'svn commit',
            RCS_LABEL => '@ :',

This enables you to use "make ci" to commit your changes. That's not
really useful, but it's neat.

(Comments welcome. I plan also to put this on my website.)
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Not to be picky, but does anyone else find autogenerated changelogs unhelpful? IMO a changelog should describe the overall changes and their effects rather than the detailed code modifications. If a hacker is interested in the steps taken to achieve these changes there's always 'cvs log' -- or the svn equivalent :-)
    • I guess that it depends on your project and on your audience. I happen to like verbose changelogs, and tools that write them for me (provided I've been careful with my commit messages). For example, perl comes with extra-large detailed autogenerated changelog files. This doesn't prevent me to write elsewhere (eventually ;-) a short summary of what has changed recently. I don't do that because I don't maintain anything mainstream.

      Moreover, noone will be able to 'svn log' my repository if it's not network-ac

      • It's not verbosity/length that I object to, it's that people looking to see what's changed need to be intimately familiar with the code structure to figure out what's going on. You could say we're discussing two separate items -- to use your example, Perl's detailed auto-generated changelog file versus 'perldoc perldelta'. It's great having both, but having the former without the latter isn't useful. (IMO, of course.)
        • Having written few perldeltas I can say that automating that process is highly unlikely. Condensing hundreds or thousands of patches into an "end- user" description requires days of hard work, and many editing rounds.

          I have to mention one common fallacy people seem to have that one patch equals one fix / one feature. Well, yeah, rarely it does work like that. But usually the mapping is many-to-many.

          But without the autogenerated verbose changelogs
          one would be very hard pressed to be able to write the more
          • I concur. I like perldelta or somesuch for a summary of changes, but I like the generated changelog for specifics. Perl's Changes file has helped me innumerable times, but I wouldn't want to have to read that to see what important things have changed in a new release.