This is actually already implemented and has a 100 process limit.

This should be fine provided the cp did not also change files...
If there was a way to find out if the change is a net null, that would be
useful here.

Also, as we only use tags for markrelease on master branch, we can ignore any cross
repo tag copies as they will just clober the data we have already.

This allows us to svn mv the cauldron/PKG/current folder to a new name and
have this copied over to git.

It does not yet handle the case where subsequent commits to previous distros
for the old name are magically moved over to the new name for the repo
(which I think is the correct behaviour as noted on the sysadm mailing list)
so some kind of rename mapping will have to be kept (if I ever implement
resuming support, then this map will have to be dumped to a file and restored
again about restart)

Another problem is that the tags are apparently all squashed up due to the
svn mv commit, but this should be handled via a simple return... after dealing
with the repo rename (although some changes may get lost :( if this is not a
straight copy (i.e. svn cp + changes in the same txn)

This also renames log and marks files.

If the master branch is deleted, this typically means we are obsoleting our
package.

Rather than 'deal' with the branch deletion, simply rename the repository
and then continue.

We will likely have to deal with a later resurrection and also deal with
package renames better too (e.g. one commit renames and resurrecting
a specific package that was subsequently brought back from the dead)
but this will be dealt with in a later commit.

In our case I svn cp'ed a file from mga3 updates to mga2. With this code in place, this
caused a merge of mga3 and mga2 which made the output of mga2 git log very misleading
(it had tags and commits from v195 of systemd even tho' we were only shipping v44 there).

I don't think we'll lose anything by simply not merging here.