[Nut-upsdev] Repo conversion progress report

[Eric S. Raymond]

Charles Lepple <clepple at gmail.com>:
> Great news! Is there a copy of the Git repo that I can take an early
> look at, or is this version of the reposurgeon code committed
> somewhere?

By a happy coincidence, your reply came to my notice as I was putting
the finishing touches on that package for you.  If you fetch

	 http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz

you will get a tarball containing my surgical tools, various auxilary
files, and the complete recipe (in nut.lift) for applying them to get 
a git repository from the Subversion nut repo.  The steps, captured
in the enclosed Makefile, are:

1. Make a local mirror of the svn repo using svnsync

2. Use that to get a Subversion dump of the repo state 

3. Script reposurgeon with nut.lift

So, not only do you get the current state of the conversion, you get a
reproducible recipe for every step of the process.  I expect we will
finish the process by adding commands to nut.lift (and new
implementation logic to reposurgeon to interpret them) until what
comes out looks right to you.

> There is also that issue of SVN allowing both local and remote
> copies of files to make branches, and I've always been suspicious of
> that metadata. This is particularly evident when git-svn tries to
> understand what is going on around branch creation points that were
> recreated with the same name (windows_port, etc).

Indeed.  There's one big problem in the present conversion - a
Development branch detached from trunk - which I'm almost certain is
due to this kind of aliasing.

I think the way I'm going to have to handle this is with reposurgeon
code that recognizes branch re-creation points in the dump stream and
does something special with them - most likely refusing to delete the
old branch and instead creating a new branch with a distinguishing
suffix. 

The other problem I'm grappling with right now is merge detection. Ideally,
your feature branches should automatically or semi-automatically get merge
links back to trunk (that is, no change to content but the live end of the
branch should become the parent of some later trunk revision).  I'm trying
to debug logic to do that.  It's not easy.

The good news is that these two issues are the last ones on my list.

> If you're looking for a second set of eyes on the converted
> metadata, let me know.

This is exactly the right time for you to start looking it over. 
That's why I was preparing a tarball for you; your knowledge of
the repo history and prior conversion glitches is about to become
important.

How are your Python skills? I think at this point I could use a
collaborator to help improve reposurgeon's branch-surgery and
merge-recognition code, if you're interested.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>