[Nut-upsdev] Repo conversion progress report

[Charles Lepple]

On Dec 28, 2011, at 11:43 AM, Eric S. Raymond wrote:

> 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

Got it. I will take a closer look at it tomorrow.

>> 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 ideal name for the latest branch would be the one without a suffix, but the conversion code doesn't know that a priori. Maybe the simplest thing is to fix that up in the *.lift script? (I'm still finding my way around.)

> 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.

Similarly, this is something that might be best handled with a fixup command - especially since the merge metadata usually isn't stored in the Subversion repository. (Merge support came too late to be widely used, IMHO.) I think the results of editing out conflicts in a merge would make it very hard to detect anything other than the cleanest merges.

> 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.

They are rusty, but I'll take a look. The reposurgeon code is a lot cleaner than what I am used to.

-- 
Charles Lepple
clepple at gmail