[Nut-upsdev] Time for a distributed VCS?

[Charles Lepple]

On Nov 26, 2011, at 10:19 AM, Eric S. Raymond wrote:

> Arnaud Quette <aquette.dev at gmail.com>:
>> Charles has already applied the painless, rapid and metada-preserving

Arnaud, these are not the adjectives I would have used to describe the initial conversion process :-)

>> approach: https://github.com/clepple/nut
>> but he will probably elaborate more on this, and the last point (preservation).
> 
> Cloning...right, I see what he has done.  This is a normal mirror site
> using git-svn.  It's a good start, but there are a couple of issues with
> this kind of purely mechanical conversion.
> 
> One is that the Subversion r[0-9]* references aren't converted.  Instead, 
> there are generated lines at the end of each commit comment like this:
> 
> git-svn-id: svn://svn.debian.org/nut/trunk@3320 72a954d1-e00c-0410-aa02-d9c7bb700a61

Eric, I think you covered this more in your "DVCS Migration" page, but I left that in for the synchronization capabilities of git-svn.

I agree it's not an ideal commit identifier, but my knee-jerk reaction is that "2011-10-25T15:11:09Z!fred at foonly.com" is only marginally better.

Maybe it's in the presentation. In announcement emails, Arnaud usually makes an effort to move long URLs to the end, much like a footnote (using something short like "[1]" in the body of the text). Something like that for legacy commit messages would work best.

The potentially confusing part is that I often used "[1234]" syntax to refer to SVN revisions (especially in merge commits) since we have a Trac instance to browse the repository. I think Trac added options later to identify the r[0-9]+ syntax.

> Another is that comments aren't massaged into git form - summary line plus
> optional blank like and details.  Doing this requires hand-editing in a
> way that isn't really practical without a support command similar to
> reposurgeon's "edit multiline".

Fully agreed. The one-line summaries make browsing history in gitk or "git log" /much/ easier.

I wanted the git-svn conversion to remain machine-convertable while we worked out the kinks of getting NUT developers up to speed on Git, but so far, nobody else has taken the bait. (We had a few people submitting patches from their own git-svn trees several years ago, but as far as I know, I am the only one using that converted repository.) I think it's time to force the issue.

> Another is that .cvsignore files aren't mapped over to .gitignore files.

Right, I have a .git/info/excludes built from the SVN metadata. Not ideal, but I didn't want the .gitignore files to get out of sync.

> Yet another is that git-svn does not detect rename and copy operations.

I'm curious about this - doesn't git only detect copy and rename when you browse the repository metadata, not when you create a commit? I may be working with old information here, but I thought that's why you sometimes need to specify "--find-copies" and "--find-copies-harder" to some Git commands.

> When I do a conversion, I translate all the artifacts from previous
> VCSes so the resulting history looks much more as though the project
> had been using git from day one.  Subversion reference cookies turn
> into committer/date pairs; junk commits like 
> 
> f6d28c0cabca44449799fc53f81dec18ea72b351 "This commit was manufactured
> by cvs2svn to create branch 'INITIAL_IMPORT_AQ'.
> 
> get removed entirely.  Rename and copy operations are reconstructed.
> My tools also do better tag lifting; where git svn renders all Subversion tags 
> as git branches, I turn them into actual tag objects.

Yes, I've been lifting Subversion tags to Git tags manually. I'm a strong believer that tags should be outside of the commit namespace (like CVS and Git; unlike SVN and Mercurial).

>> more than the DVCS battle, that is IMO already won, you may prefer to
>> concentrate your force on the next gen Forge ;-)

[some good forge comments trimmed]

I don't think the forge debate is quite as important as the format of the source code repository, although I'll probably add my two cents on forges in another thread.

We covered rewriting tags, rewording commit messages, and dropping unnecessary manufactured commits, but some oddities still remain in the NUT tree. I'm not intentionally singling out Fred, but if you look at the first few commits of both the Eaton_SDK and windows_port branch, there are some not-quite-merge commits of his which turn the Git history into a bit of a mess. I just got back from vacation, and haven't fully identified what is going on with the Eaton_SDK branch, but from what I can tell, git-svn didn't understand that the windows_port branch was re-created, and so it gave the branch several heads. If it's easy to programmatically identify such situations in reposurgeon, fine--otherwise I suggest we just manually run "git rebase -i" to squash those commits into a normal branch creation commit.

The authors file for git-svn is currently in the source tree. Feel free to edit your email address to point to your own domain. We used Alioth aliases, unless people replied otherwise: https://github.com/clepple/nut/blob/master/tools/git-svn.authors

Also, nobody on the NUT project has put forth any good reasons to use a DVCS other than Git (and the export format is becoming a de facto standard), so no arguments here.

In short, I'm all for redoing the SVN-to-Git conversion, as long as we fix up a few things in the process. What's next?

-- 
Charles Lepple