> On 26 Sep 2019, at 20:14, Brainstorms <[email protected]> wrote:
>
> 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.
Pay attention because Pharo could be better for supplanting bash.
> 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.
To help you, you can extend the inspector to provide specific view on data.
>
> 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?
To me Pharo is not really at the level I would like to. But this is my view.
Now we have nice binding to invoke shell and other like subOSProcess.
We should also progress on that front.
To me Pharo is super good at manipulating complex data and object
and building nice abstraction.
So I hope that you will not be disappointed.
>
> -t
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
