I’m moving house again. Not physical house, crikey no, that was the most harrowing experience of my life last time.. No, code hosting.

I started hosting my code on Google Code, which was a nice hosting service, but like many Google products, they closed it since they couldn’t offer the features that other hosting providers such as GitHub and BitBucket did. Read about it here.

So I moved to BitBucket, mostly using Mercurial, which I still maintain is a superior and easier-to-use system than Git. And all was good, until Atlassian, the owners of BitBucket decided to stop hosting Mercurial repositories. Not only were they going to stop users creating new ones, they were going to delete all of them. From an archivist perspective, this is abhorrent behaviour. Consider that Open Source is what most technology businesses are built on, they’ve just raised a large digitus impudicus to the Open Source world. And we’ve taken note. Read the announcement here. But it’s the forum posts that are important too, developers up in arms about the vandalism Atlassian are perpetrating, with no mechanism to auto-convert their Mercurial repositories to Git, hosted at BitBucket. The community has responded splendidly, providing tools and instructions on how to perform an exodus. I have contributed one or two simple scripts to aid with it, but mostly I’m using Magnus Hovland Hoff’s superb Kick the Bitbucket script. I have over forty repositories to migrate from Mercurial to Git, and from BitBucket to GitHub. I have to convert, update my source control tools, IDEs, build servers, references between projects on my web site, and also change all the URLs of images I place on this blog. Not a small task, and it has taken me off my main project, Parachute.

Time will tell whether Atlassian sunset BitBucket as a whole. The overwhelming view in the forum is that they have sown mistrust for all their products, with users abandoning them. Hope they keep Trello. JIRA? Hmmm..

Is GitHub a safe home? I hope so. The change of ownership to Microsoft has been good for it, I feel. Has Git improved since I started using Mercurial? A little, but it’s still a pretty grim user experience. Mitigated with Syntevo SmartGit. The command line is still a Lovecraftian horror.

While updating pages of this blog, I ran some stats. The most viewed pages are those that relate how I solved a technical problem; some irksome thing that had taken me a while to sort out, so I wrote up what I’d done. It’s nice to know that I’ve helped others in some way; tech is hard. Next come the more complete radio/antenna constructional articles. Near the bottom however, are posts on Parachute.

Perhaps I just need to do smaller things, that are more easily completeable?

16 months after picking up this old project, I’m happy to release the first cross-platform version of my T800ish Transputer Emulator!

See the Parachute 0.0.1 release notice for more details, download links etc.

As the previous blog post here described, there have been several frustrating aspects to the development- and these have only continued since then. However, I now have a good base, with mostly fully automated build/test and release systems- so subsequent releases should be easier.

One aspect of the build has been to use Maven & Jenkins for everything- despite several components of Parachute not being pure Java. Between these two, and a moderate collection of plugins, I have a multi-platform C++ build, with deployment to Maven Central.

I have a long-standing dislike of language ecosystems building their own component build/dependency/deployment systems. They re-invent Maven – sometimes poorly, usually because of a mistaken idea that it is Java-only. I’d much rather build on the existing base of Maven than see my language experiments as in some way “special”, requiring me to unnecessarily re-invent it. Maven is not perfect, but I think it’s a good fit for Parachute. I’ll still be providing build tools as command line tools and libraries, for easy use in non-Maven systems.

In the next phase of Parachute I’ll be converting the protocol between the emulator and host I/O server to be compatible with the Inmos iServer, then getting eForth working.

But first, a rest. Happy Summer Solstice!

TL;DR: Frustration, but the end is in sight.

Parachute is composed of several separate projects, with independent versions, held in separate repositories:

  • the Transputer Emulator itself, written in C++, built using Maven/CMake/Make, which requires building and packaging on macOS, CentOS 7, Ubuntu 1604 and 1804, Raspbian Stretch, and Windows 10.
  • the Transputer Macro assembler, written in Scala, built using Maven, which requires building and packaging on macOS, Linux (one cross-platform build for all the above Linux variants), and Windows 10.
  • and eventually there will be the eForth build for Transputer, other languages, documentation, etc.

Getting all this to build has been quite the journey!

I use Maven as an overall build tool, since it gives me sane version management, build capability for all the languages I use via plugins, packaging, signing, deployment to a central repository (I’m serving all build artefacts via Maven Central).

Each project’s build runs across a set of Jenkins instances, with the master on macOS, and nodes on virtual machines, and a physical Raspberry Pi.

Each project deploys a single artefact per target OS, into Maven Central’s staging repository. So there are six build jobs, one on each node, that can sign and deploy on request.

The effect of this is that a single commit can trigger six build jobs for the C++ code, and three for the JVM-based code (since all Linux systems package the same scripts). Deployment is manually chosen at convenient points, with manual closing of the staging repository in Sonatype’s OSSRH service.

The manual deployment choices may be removed once all this is running smoothly. Since I cannot produce all platform-specific artefacts from a single Maven build, I cannot use the Maven Release Plugin.

Once the emulator and assembler are deployed for all their variants, there is a final build job that composes the Parachute distribution archives, signs them and deploys them to Maven Central via Sonatype OSSRH.

There have been several ‘gotchas’ along the way..

… the GPG signing plugin does not like being run on Jenkins nodes. It gets the config from the master (notably, the GPG home, from which it builds its paths to the various key files). So that had to be parameterised per-node.

… getting the latest build environments for C++ on each of the nodes. I’m not using a single version of a single compiler on everything. A variety of clangs (from 3.5.0 to 8.0.0) and Microsoft Visual C++ Build Tools.

… Windows. It’s just a world of pain. Everything has to be different.

So this long ‘phase one’ is almost at an end, and I hope to ship the first build very soon.

It would be ‘fun’ to see if I can replicate all the above with a cloud-based build system instead of Jenkins + VMs. However, Windows, macOS and Raspberry Pi will be problematic. Travis CI does not have CentOS or Raspberry Pi hosts; Circle CI does not have Windows, CentOS or Raspberry Pi hosts (Windows is on their roadmap).

Surely, there’s something to report this month?

Well Parachute is making progress, I now have a version that runs on Windows 10, with some small niggles. It’s building on macOS, Windows 10, CentOS 7 and Ubuntu 1604. Now working on the final packaging builds that’ll bring together the emulator, assembler, example program (which is the essential ‘Hello World’ in assembler) and eForth into a single distributable package for each platform.

I’m also starting to read up on theory relating to the Transputer, occam, and the process algebra it’s based on, Communicating Sequential Processes. More on this (a series of rough notes on the papers and books I’m reading) later.

The magnetic loop is still waiting for me to work out how to do brazing, to connect the copper pipe loop to the variable capacitor in a manner that keeps resistance to a minumum.

The digital modes transceiver keeps knocking around in my head, although I did find an archived copy of the Elektor issue that describes the LUFA library. It’s http://d1.ourdev.cn/bbs_upload782111/files_43/ourdev_663216L8BOSE.pdf

In terms of goals, my CW goal is utterly shot. I’m still keeping up with the Bulgarian Station Blagovestnik’s special event stations – I’ve managed to contact all of them so far, including this month’s via some extremely shaky CW (I must pick up CW practice again.)

I have various other fitness/study goals (abstract algebra, category theory, stoicism) and commitments that are noodling along slowly… but finding time is always the difficult bit.

One thing that’s being stuck at solidly is meditation: I’m making time for it every day (with a couple of unavoidable exceptions). As Voltaire said, “The more you read without thinking, the more you think you know a lot but the more you meditate, the more you see that you know very little.”

I know so very, very little.

Back in July 2017 I wrote a post on here in which I gave a rough sketch of a combination transceiver/computer that would allow me to take a single unit, antenna kit and power, and work digital modes portably, with a minimum amount of baggage. Like one might do with the Mountain Topper range of CW transceivers, but capable of operating with digital modes.

When I wrote the article, I was into JT65 and JT9. Now of course, FT8 is the mode du jour.

The DDS of choice was the ‘el cheapo’ AD9850/AD9851 boards that are available on eBay: now I’d go for the Si5351 DDS boards, with a module available from Adafruit, and also available in an ‘el cheapo’ variant! This DDS creates fewer harmonics.

I’m still very much a beginner at RF design: that is still the major risk to the project, as is the absence of copious amounts of spare time in which to work on it!

However, one risk I’d identified – making an Arduino present itself as a sound card + multiple serial devices – seems to be reducible. LUFA (Lightweight USB Framework for AVRs is a “an open-source complete USB stack for the USB-enabled Atmel AVR8 and (some of the) AVR32 microcontroller series, released under the permissive MIT License”. It has examples of Audio In/Out and Serial devices. I’m hoping it can also provide a composite device that allows the single audio I/O channel, and two serial ports (diagnostic and CAT control).

So the next action on this project is to make an Arduino Micro look like a sound card with two serial ports. It’ll be a loopback device, so whatever sound you play at it (i.e. when transmitting) will be played back to you when receiving; whatever you send on serial port A will be echoed back to you with a ‘DIAG’ prepended to it; similarly with port B as the ‘CAT’ port.

Still unknown: SSB transceiver design that’s buildable by a beginner, and that can be connected into a ADC / DAC pair. How many bits of audio do I need to sample, at what rate?

This may well require a microcontroller that’s a bit more powerful than my usual Arduino Micro – possibly one from the Teensy range.

… to be continued…

Ah, the optimism of the 1st January!

As I reflected on 2018, it became apparent that ‘starting, not finishing’ is a big problem, chez M0CUV. My muse bestows plenty of interesting ideas, but some of them are a bit ambitious. I start, then things grind to a halt. This, coupled with chronic procrastination means a lot of churn, and a feeling of dissatisfaction, angst, and despair at not being able to find the time to do all this – or to prioritise better. A look back through the log shows a big gap of radio silence from June to October, a page of digital mode contacts, and not a single CW QSO throughout the whole year. On the software side, I hung up my own P2P stack after a baffling test failure wore me down. I do want to return to that.. However, I spent most of my hobby development time working on the Parachute project, which despite being really tricky, is going well. I never thought writing an assembler would be this hard. The devil is in the details.

So, after giving myself a good slap for a lacklustre radio year, 2019’s going to be goal-driven. Hopefully these goals are SMART (Specific/Stretching, Measurable/Meaningful, Agreed-upon/Achievable, Realistic/Rewarding and Time-based/Trackable). There are quite a few, and only the tech/radio-related ones are blogged about here. I’ve been using the Getting Things Done method for a while, and it stresses the importance of defining the Next Action on your activities..


  • 1 blog post/month, at least. Progress updates on projects, etc.
  • 1 CW QSO/month, or 12 in the whole year. This’ll probably be really tough.
  • 1 QSLable QSO/month, or 12 in the whole year, any mode/band. FT8 makes this much easier!
  • Try to contact each month’s special callsign for the Bulgarian Saints award from Bulgarian Club Blagovestnik. I’ve already bagged January’s, LZ1354PM via SSB on 1st Jan 🙂
  • Take the next step on the magnetic loop project: build the frame, house the capacitor. I bought some wood and a food container for this yesterday.
  • Box up the 30m QCX transceiver properly – then use it.
  • Keep up with magazines as they arrive rather than building a pile of them.
  • Fix the current bizzare bug in the Transputer assembler – then ship the first release on Windows, macos and Ubuntu/Raspbian
  • Convert the Parachute Node server to use the IServer protocol – then write the IO code for eForth.
  • Build a web application with elm. I’m thinking of a web-front-end to WSJT-X, to allow me to operate remotely.

Let’s see how I get on…!

A busy year, but very few blog updates, hence this one.

A couple of amateur radio projects started, but not finished (QCX built but not boxed; magnetic loop put aside; digital all-in-one transceiver idea written up but no more done; EasiBuild MkII stalled after I fried the DDS and buffer amplifier). I also joined West Kent Amateur Radio Society, after not being a member of a local group for many years, and would like to (find time to) work some contests with them, something I’ve never tried before. An attempt at running a special event station was not very successful but there will be future opportunities.

“Finding time” has emerged as my major problem.

I became a blood donor again after several years not doing it – if you haven’t considered donating, please find your local donor centre and make an appointment: you could save lives.

Open source development ground to a halt on my peer-to-peer project due to a bizzare interaction & test failure I couldn’t fathom… so it went on hold.

I’d been considering getting my old Transputer emulator up and running again, and this turned into my main open source project from March onwards. I’ve made quite some progress on it – but won’t write more here… see The Parachute Project for the writeup. Next year’s updates should feature this project quite a bit, as I feel it has legs..

As for 2019 and its goals, I hope to write more frequent updates here and make more small software releases. I’m also hoping there’s more radio activity and construction!

It’s fun to take a minimum of equipment out to a high place, lob a half-wave long wire antenna up into a tree, or support it with a fibreglass pole, and off you go – but such a long wire typically has a high (2.5kΩ to 3kΩ) impedance. To make it work, this needs transforming down to match the 50Ω output of a typical transceiver. This is done using a 49:1 autotransformer, built on a small toroid.

This post details my construction of the end-fed half-wave autotransformer and antenna for the 10m, 20m and 40m bands.

The antenna is very effective, can be erected in a variety of ways, exhibits low noise, doesn’t cause any RFI in the shack (use a choke balun in addition), places the feedpoint very near to your transceiver and it’s pretty easy to build.


There are many other articles out there on this subject:

There are also several other pictures of builds I’ve used to assist in this project, particularly from Ian MW0IAN and Michael G0POT. Thanks!


I hope to add some detail and pictures for the terrified constructor in this article, but the above are my source materials. This antenna and its autotransformer are a great project for those new to construction – the toroid winding isn’t hard.

One problem I find in many projects is that they go from diagram to finished construction very quickly with insufficient detail. It’s a bit like “How to Draw an Owl”….

How To Draw An Owl

So I wanted to document what I’d done, in the hope it might be useful to others, especially if you’ve not wound toroids before. The key point is that the count of ‘turns’ relates to the number of times the wire goes through the inside of the toroid.

Parts and materials

I’m building this autotransformer on a FT-140-43 toroid, purchased as a pack of two on eBay from Spectrum Communications, for £9.50 incl P&P.

I first wrapped this in plumber’s PTFE joint sealing tape.

I’m using Maplin 0.9mm 20SWG enamelled copper wire, code YN82D. £8.49 for a small reel (the picture on their page is misleading; it’s not as small as indicated). The source articles used 1.0mm wire; this will allow higher power to be transmitted – I’m mostly QRP, and without calculating it, 0.9mm will be fine for this.

For connectors, I’m using a BNC socket, £2.49 for Maplin’s code HH18U, and a small terminal post, again £2.49 for Maplin’s code FD69A. A small black plastic box, for £3.39 code KC91Y houses the completed autotransformer. This box is a bit ‘tight’, but it does all fit. You’ll also need a 100pF 3kV ceramic capacitor, available for £0.131 each (min order, pack of 10) from RS Components.

Building the Autotransformer

Wire lengths for the toroid winding given here come from reading other articles which describe builds on the larger FT-240-43 toroid. After I’d wound on the smaller toroid as shown here, I had some waste wire that required trimming – you could start with shorter pieces of wire, and I’ve estimated possible lengths for this [in square brackets]. However please note I haven’t tested those lengths.

Measure two lengths of wire, 1.0m, and 22cm. [For the FT-140-43 toroid, and a small box as given above, you could probably use lengths of 80cm and 18cm.] Strip the enamel from the ends for about 2-3mm, clean with sandpaper and tin with solder. Solder the two right-hand ends together.

Solder the right-hand ends together

Holding the soldered end in pliers, twist the two lengths tightly together for 13cm [for the FT-140-43, 9cm may suffice], to form the bifilar winding. ‘Bifilar’ meaning ‘two filaments’, I presume. The remaining length of the shorter piece of wire (at the end of the bifilar winding) being about 6-7cm long. Let’s call this length ‘the tail’.

Now to wind the bifilar part onto the toroid.

Pass the bifilar part through the toroid from the back, so that the ‘tail’ passes under the bottom edge, and the start of the bifilar part is entirely running through the inner of the toroid.

Starting the Windings

Wind the bifilar part back round the top and outer edge of the toroid, and back through the hole. Bend it again over the top. You should have two bifilar passes through the toroid. The end of the bifilar winding (that’s the soldered-together end) will be connected to the outer/shield/chassis connector of the BNC socket. The end of the tail will be connected to the inner/centre connector of the BNC. I’ll get back to the connections later.

The Bifilar Winding

Now, there’s the rest of the toroid to wind.

Wind the long single strand of wire through the toroid so that you have six passes on the inside.

The first part of the rest of the winding

Then pass the wire over the top, and over to the other side, going under the far edge. Loop over the top, and go back through the toroid so that on the far side, you have seven passes, with the remaining end (‘the antenna end’) going under and out.

Ensure that the windings are spaced as evenly as you can.

The final winding

Now tin the connections of the BNC socket and terminal post, and fit them in the box.

Carefully trim the three wires coming from the toroid to fit; scrape off enamel (might need to unwind the end of the bifilar winding a couple of mm to do this properly), clean and tin the ends.

The toroid, trimmed, with box

Solder the bifilar winding to the outer of the BNC; the ‘tail’ at the end of the bifilar winding to the centre pin of the BNC; the ‘antenna end’ to the terminal post.

Solder a 100pF 3kV ceramic capacitor between outer and centre connections of the BNC. Use a hot glue gun to fix the toroid to the inside of the box (not shown).

The assembled autotransformer

Put the top on the box, and there you have it.

The completed autotransformer

Building the antenna

There’s a long antenna wire attached to the autotransformer terminal post, followed by a coil and a further bit of wire. I used fairly rugged plastic-insulated wire; the outer diameter is 2mm, bought years ago on a 100m reel, probably from Maplin.

auto |         Length L1           Coil in uH    Length L2  (fibre-
xfor-|=----------------------------|\\\\\\\\\|------------|  glass
mer  |                                                    |   pole)
-----+                                                    |

For 80m+40m+20m+15m+10m, L1 is 20.35m, the coil impedance is 110μH, and L2 is 2.39m.

For 40m+20m+10m, L1 is 10.1m, the coil is 34μH, and L2 is 1.85m. I built this variant.

These lengths are taken from the diagrams in the PD7MAA article. Also see PA3FRP’s notes.

I had a length of plastic tube with an outer diameter of 15mm; I wound 141 turns of the Maplin 0.9mm 20SWG copper wire on this, and measured 34μH. This was very much a trial and error exercise; I had no idea how many turns it would take, so the initial length was extended by soldering more on, several times.


I attached the far end of the wire to the top of my 7m SOTABeams fibreglass pole, and fed the wire out so that the autotransformer was on the ground – imagine a right-angled triangle with a bowed hypotenuse; I also lifted the autotransformer up onto a small table.

Measurements with an antenna analyser show very favourable SWR readings for the three bands I’m interested in:

  • At 7.305MHz, SWR is 1.21:1
  • At 14.318MHz, SWR is 1.14:1
  • At 27.780MHz, SWR is 1.15:1

With a bit of adjustment, and appropriate positioning – it does seem sensitive to its location above ground (this is explained in the test article by John Huggins) – I think it’d be fine to transmit into this. I’d ideally like to tune it a little more, so I can use it on the exact frequencies I frequent without an ATU.

Article updated 26 Feb 2020 to change URLs of images to GitHub radio-projects repo.

I’ve been wanting to try a different aerial for 20m for some time. I currently either use a dipole in the loft, or a temporary SOTAbeams linked dipole on a 7m fibreglass mast. The magnetic loop antenna appeals because it’s compact, and if designed/built for efficiency, gives excellent performance.

They’re also expensive. One well-known UK dealer is selling the Ciro Mazzoni baby loop for £1299; another dealer sells the MFJ-1782X for £439; the Chameleon CHA F-Loop is available from a third dealer for £399. All are far, far outside my budget.

It’s not called amateur radio for nothing, and what I describe in this series of articles is truly amateur. I’m going collate my research sources, and try building a magnetic loop antenna (properly called a small transmitting loop antenna) using bits from my junk box, making good use of the things that I find, things that the everyday folk leave behind. I don’t have all the parts, but whatever I need to buy must not break the bank. Similarly, tools: I’ll need some, but they must be cheap 🙂


Abstract: Oracle is shutting down Kenai and Java.net on April 28, 2017, and as one of the open source projects I’m a member of was formerly hosted there, we needed to move away. This move comprises source code and mailing lists; this post concerns the former, and is a rough note on how I’m migrating svn repositories to git (hosted on github), with the method, and a script that makes it easier.

It’s an ideal time to migrate your subversion repositories to somewhere else, and since git/github are the de facto/fashion standards these days, you may want to consider converting your entire history to git, and hosting it at github. (Disclaimer, I prefer mercurial and bitbucket, and some of the below could be used there too…)

To convert a svn repo to git, and push to github, there are several stages. I did this on OS X – I’d do this on some form of UNIX, but you may get results with Windows too.

I’m going to use svn2git, so let’s get that installed:

Following the installation instructions at https://github.com/nirvdrum/svn2git

I made sure I had ruby, ruby gems, svn, git, and git-svn installed (these package names might not be precise for your system; they’re from memory)
I can do:

$ cd /tmp
$ mkdir foo
$ cd foo
$ git init
$ git svn
git-svn - bidirectional operations between a single Subversion tree and git
usage: git svn [options] [arguments]
… blah blah …


$ sudo gem install svn2git

The conversion from svn to git makes a lot of network access to the svn repo, and so to reduce this, let’s “clone” the svn repo onto the local system.
Mostly following the notes at https://journal.paul.querna.org/articles/2006/09/14/using-svnsync/, first, initialise a local repo:

$ mkdir svnconversion
$ cd svnconversion
$ svnadmin create svnrepo

Note that git’s svn code expects the subversion repo it converts to have a filesystem format version between 1 and 4, that is, up to Subversion 1.6. So if you have a version of the svn client that’s more recent than that, you’ll have to use the command:

$ svnadmin create —compatible-version 1.6 svnrepo

(see http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html for details)

$ ls -l svnrepo
total 16
-rw-r--r-- 1 matt staff 246 1 Sep 22:58 README.txt
drwxr-xr-x 6 matt staff 204 1 Sep 22:58 conf
drwxr-sr-x 15 matt staff 510 1 Sep 22:58 db
-r--r--r-- 1 matt staff 2 1 Sep 22:58 format
drwxr-xr-x 12 matt staff 408 1 Sep 22:58 hooks
drwxr-xr-x 4 matt staff 136 1 Sep 22:58 locks

$ cd svnrepo

Now create the pre-revprop-change hook:

$ echo '#!/bin/sh' > hooks/pre-revprop-change
$ chmod 755 hooks/pre-revprop-change

Let’s prepare to sync the svn repo here:

$ svnsync init file:///tmp/svnconversion/svnrepo https://svn.java.net/svn/name-of-remote-svn-repo

Now let’s do the actual sync. This is what takes the time on large repositories…

$ svnsync --non-interactive sync file:///tmp/svnconversion/svnrepo
# Make tea…

OK, now we have the “clone” of the svn repo, so let’s convert it to git. The first thing you’ll need is an author mapping file. This converts the short author names used in svn commits into the longer “name ” form used by git.

Note there are many possible structures for svn repos, with the ‘standard’ layout having branches/tags/trunk. This page assumes that your svn repo looks like that. If it doesn’t, then see https://github.com/nirvdrum/svn2git where there are many possibilities documented to aid your conversion.

See the svn2git github page for details of how to create this authors.txt file.

Converting to git is as simple as:

$ cd /tmp/svnconversion
$ mkdir gitrepo
$ cd gitrepo
$ svn2git —authors ../authors.txt file:///tmp/svnconversion/svnrepo

Then create a new repository using the GitHub web UI, add it as a remote, and push, mirroring all branches to the remote:

$ git remote add origin https://github.com/your-repo-name.git
$ git push --mirror origin

The following is a script I wrote to make it easier to perform the above steps repeatedly, as I had several repositories to convert. It assumes you have exported the GITORGANISATION environment variable.


usage() {
	echo "svn-to-git-conversion [syncsetup|sync|convert|push] http://url/of/svn/repository local-repo-dir-prefix ~/path/to/authors"
	exit 1

# syncsetup, sync, convert or push

# https://svn.java.net/svn/jxta-c~svn

# prefix of relative folder (eg jxta-c) where repository will be svnsynced to eg jxta-c-svn
# and of relative folder where repository will be converted eg jxta-c-git

# path to author mapping file

if [ "$PHASE" != "syncsetup" -a "$PHASE" != "sync" -a "$PHASE" != "convert" -a "$PHASE" != "push" ]

echo local svn repository url is $SVNREPOFILEURL

if [ "$PHASE" = "syncsetup" ]
	svnadmin create --compatible-version 1.6 $SVNREPONAME
	echo '#!/bin/sh' > $SVNREPONAME/hooks/pre-revprop-change
	chmod 755 $SVNREPONAME/hooks/pre-revprop-change

if [ "$PHASE" = "sync" ]
	svn propdel svn:sync-lock --revprop -r 0 $SVNREPOFILEURL
	svnsync --non-interactive sync $SVNREPOFILEURL
	echo Users in the SVN repository to be added to the $AUTHORS file:
	svn log --quiet $SVNREPOFILEURL | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | sort | uniq
	echo Top-level structure of the SVN repository: 

if [ "$PHASE" = "convert" ]
	svn2git --authors $AUTHORS $SVNREPOFILEURL

if [ "$PHASE" = "push" ]
	git remote add origin https://github.com/$GITORGANISATION/$GITREPONAME.git
	git push --mirror origin

Next Page »