I have found a project that I think is a good fit in size & complexity, one
that can operate at that "CLI level" (i.e., doesn't need a GUI or a web
front end).
We ("we" being my group and a number of projects around the Laboratory we've
been associated with) are migrating code from a Subversion server to a
central "Enterprise" GitHub (not publicly accessible). I'm the admin for
this particular SVN server, so I'm doing the migrations. Having assumed
most all of the group's devops functions over the years, I frequently have
to write code to automate tasks like these. That puts me in an good
position to write these tools in Pharo instead of Bash or Lua or Python,
etc. as I normally have been doing.
Some of the SVN repos convert nicely, using available migration tools (such
as 'svn2git' or 'git svn'). However, many developers are insufficiently
trained on VCS, and over the years many of the SVN repos have been choked
with inappropriate files and have had their history threads tangled up -- so
they will not covert. I've studied the internal structure of SVN repo dump
files, and I have algorithms (and some code in Bash & Python) that allow me
to edit these files to make them convertible. Still, it's a lot of
hand-work; a more comprehensive solution is needed.
I'm going to make a tool, in Pharo, for general editing of SVN dump files:
to remove junk that doesn't belong, extract single projects from mixed-use
repos, simplify history for tangled moves, etc. The output will be clean
dump files containing the extracted project-specific commits that will then
roll into GitHub without issues and show up with branches, tags, etc. as
expected.
While researching how to do this, I've converted 3 of >80 repositories
(which resulted in 15 project repos grouped in 3 GitHub Organizations). My
methods work; I just need to fully automate the process so that I can
complete the remainder.
Ironically, I'm not actually being funded to do this as one of my "normal"
job tasks -- certainly not the automation part. As a result, this has
become a "nights and weekends" effort. But that means I will own the code
-- so I plan to put it on the *public* GitHub, with an MIT/Apache
open-source license. Of course, everyone else who's been frustrated trying
to convert complicated SVN repos into GitHub will have my Pharo tool to use.
(That could result in a lot of exposure to Pharo..??) And it allows the
Pharo community to potentially help, since they'll have access to the source
code as well.
This kind of project does not require a GUI (it will be run by Linux admin
types) and it does not benefit from a web interface. It's mostly file I/O,
with some parameters that need to be negotiated with the user once the SVN
dump file has been scanned. Challenging, but not too challenging.
>From there I can advertise its use around the Lab. We're not the only group
that's been using SVN. Some other sysadmins are likely to want
modifications... A start?
-t
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
