[Twisted-Python] Twisted Project Jobs Volunteer

[Tim Allen]

On Mon, Nov 14, 2011 at 01:33:45PM -0500, Glyph wrote:
> Really the most important thing here though is just to get the
> automatic mirroring initially set up, not the never-ending
> ambassadorial work.  That way git users wouldn't _need_ elaborate
> instructions as to what to clone and how; if we just say "get twisted
> from github" and have that automatically updated it would be easier
> for everyone.

I've done some experimentation, and (as best I can tell) it's impossible
to use git-svn to create a sensible SVN → Git conversion of the Twisted
repository. This is because of the various, inconsistent branch-naming
schemes that have been used over Twisted's long history.

As best I can tell, git-svn can import branches that exist at some
specific depth in the tree... so if your branches look like this:

    root
    |
    +- branches
	|
	+- add-a-feature-1234
	+- fix-a-bug-2345
	+- release-v1.0.x
	+- release-v1.1.x

...you can say "git svn clone --branches='branches/*'" and they'll be
imported as Git branches. Likewise, if you group your branches in some
way:

    root
    |
    +- branches
	|
	+- topic-branches
	|   |
	|   +- add-a-feature-1234
	|   +- fix-a-bug-2345
	|
	+- release-branches
	    |
	    +- v1.0.x
	    +- v1.1.x

...then you can say "git svn clone --branches='branches/*/*'" and
they'll all be imported cleanly. Unfortunately, the Twisted repository's
"branches" directory contains subdirectories representing branches *and*
subdirectories representing groups of branches... and *those* contain
both branch directories and branch-group directories. Here are the
branch-group directories I've discovered so far:

    branches/
    branches/releases/
    branches/releases/conch/
    branches/releases/mail/
    branches/releases/names/
    branches/releases/words/

When I import a range of revisions that happens to include a change to
a branch in "branches/releases" (I've been using the range 33049:33062
for testing), git-svn winds up importing the entire "releases" subtree
as a branch, which is... suboptimal. If I use the "--ignore-paths"
option to ignore everything under "branches/releases", then it still
generates the branch and faithfully records all the commits affecting
it... but ignores all the files, so when you check out that branch it
deletes everything in your working directory.

What's really annoying about this is that git itself doesn't care about
branch naming, and it's perfectly happy to have "add-a-feature-1234" and
"releases/v1.0.x" as branch names. It's just the git-svn tool not being
flexible enough. A quick Google doesn't reveal much in the way of other
people who have dealt with repository layouts like this, except for one
report which basically went "use 'svnadmin dump' to export the
repository, use sed to rewrite all the paths, load the dump into a new
svn repository and import from there." That sounds like a lot of work to
me, and not the sort of thing that could be reliably repeated to keep
the two repositories in sync. Perhaps someone should file a bug with the
git-svn maintainer, if only they had a bug-tracker.

So, would a repository with a huge, bogus "releases" branch be
acceptable in an Official Mirror? It's not strictly needed for
developing patches, but it *will* create lots of puzzled frowns and
annoyance, perhaps from people who want a Git mirror to integrate with
their "automatically download new releases" code.

Also in the spirit of writing things down so future contributors can
figure things out, I note the Git FAQ on the Git Wiki has a "How do
I mirror a SVN repository to git?" question:

    https://git.wiki.kernel.org/articles/g/i/t/GitFaq_ebc3.html