Add Mageia README and rules for conversion.

2 files changed, 81 insertions, 0 deletions

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..de02ec1
--- /dev/null
+++ b/README.md
@@ -0,0 +1,32 @@
+# Mageia Package Git Conversion Repository
+
+This is a repository for converting the Mageia Package Repository to git using KDE's [svn2git](git://gitorious.org/svn2git/svn2git.git)
+
+There are some additional changes on top of the [KDE code](git://gitorious.org/svn2git/svn2git.git) (all kept in the distro/mga branch) to fit our particular needs. Some changes might be generic enough for use by other projects but some are just to specific to our use case. We'd like to thank KDE very much for working on the tool and making it generic enough for use to adapt.
+
+----
+
+## Running
+
+    $ ../svn2git/svn-all-fast-export --identity-map ../svn-git-migration/metadata/mageia-user-map.txt --rules ../svn2git/rules/mga-pkgs.rules --skip-revisions 4262,4263 ../packages/ >log 2>log2
+
+----
+
+## Some questions
+
+Question: Handling renames (what do to generally as updates to old branches... should we have a rename map for branches to fake the repo name, or use symlinks - how will we do it in git anyway for older distros - copy the git repo but clear out the branches - perhaps that's what we should do now, but how about reanmed repos... e.g. git-core -> git?)
+
+----
+
+## TODO
+
+1. Read repository information from files on startup (to reinitialise repos)
+2. Implement upper limit on fastimport processes that run concurrently (we'll need lots of them so this might get overwhelming!)
+3. Track repo renames better to allow for cauldron renames but mgaN-1 updates (also maintain state on disk and read on startup)
+4. Handle resurrections/renames from non rev-1 revisions (i.e. a simple, atomic svn mv works fine, but an svn cp -r xxxx to resurrect and old package (or restore from obsolete) will not work... restoring from obsolete is tricky as we may need to migrate changes fully in the commit (undoing changes that were made after the revision we want to restore))
+5. Write a verification routine script (validate master+branches in their final state only - if the changes that got us there are a bit wrong, then tough)
+6. filter-branch to tidy up the directory layout. Something like:
+
+        git filter-branch --tree-filter 'if [ -f SOURCES/sha1.lst ]; then mv SOURCES/sha1.lst sources; fi; find SPECS/ SOURCES/ -type f -exec mv {} . \; && rmdir SPECS SOURCES' --prune-empty --tag-name-filter cat -- --all
+
+7. Run it!
diff --git a/rules/mga-pkgs.rules b/rules/mga-pkgs.rules
new file mode 100644
index 0000000..a7131c9
--- /dev/null
+++ b/rules/mga-pkgs.rules
@@ -0,0 +1,49 @@
+# Main Package storage
+match /cauldron/([^/:]+)/current/
+  repository \1
+  branch master
+end match
+
+# Match branches of packages
+match /cauldron/([^/:]+)/branches/([^/:]+)/current/
+  repository \1
+  branch refs/heads/topic/\2
+end match
+
+# But ignore any other branches
+match /cauldron/([^/:]+)/branches/
+end match
+
+# And ignore pristine
+match /cauldron/([^/:]+)/pristine/
+end match
+
+# Tag any releases
+match /cauldron/([^/:]+)/releases/([^/:]+)/([^/:]+)/
+  repository \1
+  branch refs/tags/\2-\3
+end match
+
+# Deal with any release tags with epochs (colons make for invalid git branch names)
+match /cauldron/([^/:]+)/releases/([^/:]+):([^/:]+)/([^/:]+)/
+  repository \1
+  branch refs/tags/\2+\3-\4
+end match
+
+# Branches for older distro versions
+match /updates/([0-9]+)/([^/:]+)/current/
+  repository \2
+  branch refs/heads/mga\1
+end match
+
+# And some slightly special handling of our private infra repos
+match /updates/infra_([0-9]+)/([^/:]+)/current/
+  repository \2
+  branch refs/heads/infra\1
+end match
+
+# Epoch tag options:
+# 0+123-4.mga5
+# 0/123-4.mga5
+# 0=123-4.mga5
+# {0}123-4.mga5