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
\B\.svn\b
as well as the other MANIFEST.SKIP standard excluded files :
# Avoid Makemaker generated and utility files.
^MANIFEST\.bak
^Makefile$
^blib/
^MakeMaker-\d
^pm_to_blib$
# Avoid temp and backup files.
~$
\.old$
\#$
^\.#
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 :
WriteMakefile(
...
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
Makefile
pm_to_blib' .
$ svn commit -m 'Ignore MakeMaker-generated files in svn status' -N .
For a maximized hype, use the following options to WriteMakefile() :
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.)
Re:Autogenerated changelogs
rafael on 2002-12-04T16:39:36
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,perlcomes 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-accessible.
Re:Autogenerated changelogs
lachoy on 2002-12-06T13:43:41
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.)Re:Autogenerated changelogs
jhi on 2002-12-10T20:48:27
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 approachable descriptions.Re:Autogenerated changelogs
pudge on 2002-12-11T14:42:19
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.
