Finally starting the move to GitHub with GitHub::Extract
I am, somewhat famously, one of the last holdouts in the Perl community when it comes to moving away from svn to git.
I fought against the most for a long time, on the basis that the tool support for git on Windows was just terrible and it would make contributing to Perl difficult for Windows people.
Fortunately, with the availability of tools like SmartGit and GitHub for Windows this is no longer a problem.
So it looks like the time has for me to start the giant job of moving my repository over to GitHub myself (no small task considering it contains something like 300 modules).
As a first step, I am porting my personal release automation over to allow me to release modules from GitHub directly without the need for git client integration or a checkout at all.
The core of this new release automation is my new GitHub::Extract module.
GitHub::Extract is a wrapper for GitHub projects over the top of Archive::Extract and File::pushd and makes use of the "Zipball" feature of the GitHub website.
In a single statement you can download a project zipball from GitHub, extract it, and then change into the root directory of the exported project.
my $pushd = GitHub::Extract->new(
username => 'adamkennedy',
repository => 'test-class',
branch => 'master'
)->pushd;
# Do the rest of the release tasks here
The current working version of the new release automation is here (yes, it's in svn for now)
http://svn.ali.as/cpan/trunk/ADAMK-Release/lib/ADAMK/Release.pm.
It needs a few more small tweaks, but it deals with the things I care about and it should be good enough to start building releases from.
The next step is to start the process of porting modules into GitHub, and that seems like a much bigger job (anyone got a script for splitting one giant svn repo into lots of small github ones while retaining history?)
More to come...
I blog about Perl.
https://github.com/pseligman/git-svn-abandon
I wrote https://github.com/rcaputo/snerp-vortex as a yak for moving POE to git.
It includes a utility (snerp-projector) that splits up a converted repository into multiple projects. Subprojects have the main project history up to the point where they diverged. For example, POE::Test::Loops diverges here: https://github.com/rcaputo/poe-test-loops/commit/364246096c8de24e9ff51e83343407a8b2faa5d4
In retrospect, I should try to make it preserve commit hashes before the split. It should be the moral equivalent of a project fork and reorganize. There should be a common ancestor if someone ever wants to merge them again.
> Fortunately, with the availability of tools
> like SmartGit and GitHub for Windows this is no
> longer a problem.
I find it interesting that you consider those as the linchpins for convenient git usage on windows, since on review i found them terribly flawed because they are quite alluring, but leave out (or make hard) important git use patterns; and in doing so they promote use patterns that are actually damaging to software development. This is even more surprising since msysgit (with its native git-gui) and tortoisegit work together in very comfortable ways and aid software development in such a way that they turn out better software with a cleaner history.
If you're interested i'd like to discuss this on IRC to compare notes. :)
Don't forget to share the notes here :)
@Mithaldu I don't have time to discuss it on IRC at the moment, but I'd love to see a blog post or a write up on why those two clients are problematic.