On Apr 15, 2012, at 7:33 AM, Arnaud Quette wrote: > nice, still on the road to git ;-) > how far, according to you, from the migration target?
I think it depends on how much we want to look at the converted Git repository as the "official" history, versus an approximation (with the SVN+Trac history still available for reference if things get confusing). But maintaining a read-only SVN repository is a bit of an annoyance. We are pretty close to being able to do development on the Git repository as it stands now, but then again, we were able to do that from the git-svn conversion, too. The problem is that cleaning up additional things in the reposurgeon conversion will change hashes for some of the commits, which will make it even more annoying than using SVN for NUT development (since changes will need to be rebased). That's why I'm pushing so hard to get things correct the first time we switch over. Since it is so hard to measure how long this will take without just doing it, let's compare it in terms of complexity of things we want to do with the NUT tree. Releasing 2.6.4 from the current trunk shouldn't be an issue with SVN. Merging one or two small branches (e.g. the Coverity fixes) shouldn't be hard in SVN, either (optionally with some help from the git-svn tree for rebasing, since those Git revisions will get merged into a single SVN commit). Merging something as complicated as windows_port via SVN is not recommended at this point, IMHO (due to the tendency for conflicts, and for files to get lost in the merge process). So I'd say that if we want to merge the windows_port branch, we should put that off until after the Git conversion. Otherwise, we can continue with SVN and keep working on the Git conversion in parallel. PS: if you want to refer to a previous SVN commit in the text of a SVN commit message, I think we should standardize on the "[[SVN:1234]]" fossil ID notation that Eric has been using in the reposurgeon conversion (which is machine-parsable). It should be easy for me to adjust the Trac code to create a link the same way that it does for "[1234]" and "r1234". Same goes for merge commit messages: "[[SVN:1234]] to [[SVN:1239]]" -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
