Migration (import) of v1.0 (pre-April 2012) development history

[hlapp]

The development history of CDAO up until and including v1.0 (http://www.evolutionaryontology.org/cdao/1.0/cdao.owl) (the version originally published) has remained in a CVS repository on SourceForge.net.

The earliest release published under the purl.obolibrary.org URI is essentially that v1.0 version, so I wanted to see whether we can preserve the history of that somehow.

I've now managed to migrate the CVS revision history of the v1.0 release to Git (using git cvsimport and cvsps v2.1 compiled from source). I've pushed up the results here as sf-cvs-trunk, sf-cvs-arlin, and sf-cvs-Enrico_May. The sf-cvs-trunk branch presents a continuous history from 2008-2011 and is what one might consider as the "main trunk" in CVS or master in Git parlance. sf-cvs-arlin seemed to have ended very early on. sf-cvs-Enrico_May contains a significant amount of early history that isn't obviously redundant with the main trunk (using solely commit log messages) but ends years prior to the main trunk; it may have been a tag?

Ideally I would want a continuous history from the beginning to now. That would require grafting the master branch onto the head of sf-cvs-trunk. I could try doing that but the changes would be so drastic that on the level of each file there wouldn't be any continuity worth speaking of. The only exception may be cdao.owl, but that file changed location (from OWL/cdao.owl to the repo root directory).

Thoughts on the merits of this and which CVS migration results (the branches enumerated above) to keep around and which ones not to are welcome.

Tagging @arlin, @epontell, @rvosa (and @bchisham - can't identify the Github user corresponding to F. Prosdocimi).

[hlapp]

I think I've found a reasonable compromise, by creating a graft of the new history (which was started in svn by @balhoff, and which I then migrated to git) to the old history (which was versioned in CVS, and which per this issue I now also migrated to git).

The graft is currently a parent replacement and shared as such (*) through this repo, meaning it is not permanent, and no history has been rewritten yet. Those who want the grafted-together history need to explicitly fetch the graft (i.e., the parent replacement):

$ git fetch origin 'refs/replace/*:refs/replace/*'

Neither git fetch nor git clone will retrieve these by default.

After you have fetched the replacement, git log and other commands by default show the continuous history from the very first CVS commit. The move of OWL/cdao.owl to cdao.owl is auto-detected, and hence we can now follow the complete history of the file across renames:

$ git log --follow cdao.owl

This now goes back to April 9, 2008 (bd696d5e88a1a612d58957f1940e67f1a571e1dd).

Note that commit replacements can be disabled for any git command by --no-replace-objects. The following only goes back to April 11, 2012, the start of the svn repo history (40040443f88e6766bf1c0a759316a21e1b177a88):

$ git --no-replace-objects log --follow cdao.owl

The parent replacement can be made permanent (using git filter-branch), but that requires rewriting the history. This may well be a good option – so far, the git history here is solely a migration from svn and cvs anyway, is kind of still in review phase (hopefully no forks yet, and no locally modified clones?), and all that rewriting would do aside from making the graft permanent is to change all commit SHA IDs. (Rewriting history does not change order, commit dates, or metadata other than the commit ID.)

Thoughts on making the graft permanent vs. leaving the graft as a the commit parent replacement?

[balhoff]

I haven't cloned - probably a good time to rewrite the history, and I don't see why not to do it.

[hlapp]

probably a good time to rewrite the history, and I don't see why not to do it

I've done this now. I also saved the old svn import line of history under the sf-svn-migration tag.

Subsequent to that I have now also ported the release tags, see #4. (The versionIRIs won't resolve to those until we update the OBO metadata record.)

[hlapp]

I think we can call this complete now with the review and creation of the release tags corresponding to all releases published earlier under their own IRI or versionIRI. See #5 for updating the OBO metadata record.