Who can make LWP understand svn://?
I want LWP to understand the source control schemes, like
snv://. I almost got to look into this for this week's project, but it got pushed down the wish list. It's something that I'm going to want later though (like, at the Vienna QA Workshop). Is this an easy project for anyone?
The future of CPAN is moving away from a monolithic, central repository. You're always going to have that available, but a lot of work to make localized, custom, and even historical repositories available. I'd like the CPAN tools to be able to pull from more than just FTP and HTTP sources.
For my DPAN work that creates customized CPAN-like repositories, a couple of clients want to version their DPAN repository under source control. That can be very handy to bisect problems in application deployments. When did the collection of distributions in the DPAN break our application? Checkout an earlier version of DPAN, deploy, and test. Do that until you find the distribution upgrades where the application breaks. I'd like to pull directly from source control without setting up a webserver too.
For another use case, consider David Cantrell's CP*AN project that breaks out CPAN into repositories as they work for specific Perl versions (CP5.6AN) or specific architectures (cpNETBSDan). Those could be branches in source control. If you can make the right source-control specific path and LWP knew what to do with it, you could easily switch repositories by just using the right branch.
The CPAN.pm understands. In practice, that's either FTP or HTTP (and David Golden is working on making that even better). If you put your source control behind a web server, you can just use HTTP. What if you want to talk directly to the source control server, using
git://, or another scheme? So far, LWP doesn't know what to do with those. I want to do something like:
use LWP::Simple; my $file = get( 'svn://...' );
The real goal is put that
svn:// in the CPAN tool configuration:
cpan> o conf urllist unshift svn://...
I don't need LWP to understand the entire interface to the source control systems: if it can fetch a single file from either the head of the repository or a named commit, that's good enough.