On Wed, 2013-01-02 at 15:05:43 -0500, Dave Abrahams wrote: > > on Wed Jan 02 2013, Ulrich Spörlein <uqs-AT-FreeBSD.org> wrote: > > > On Wed, 2013-01-02 at 12:53:02 -0500, Dave Abrahams wrote: > >> > >> on Wed Jan 02 2013, Gitorious <no-reply-AT-gitorious.org> wrote: > >> > >> > Hello dabrahams > >> > > > > >> > uqs has sent you a message on Gitorious: > >> > ---------------------------------------------------- > >> > > >> > Hey, > >> > > >> > there's really not much infrastructure involved in doing so, you need > >> > to get direct access to the SVN repo somehow (most likely by using > >> > svnsync), then write your rules and a cronjob that runs svnsync, > >> > svn2git, and perhaps a push to github or gitorious, periodically. > >> > >> Well, OK, we're doing that. I think we're going to push to bitbucket > >> because it offers a real commit graph... oh, interesting, Gitorious does > >> too, now. Perhaps we'll try both. > > > > The more the merrier! :) > > > >> > I'm doing just that for the FreeBSD repositories, > >> > >> Oh, wonderful! > >> > >> > mail me at uqs-AT-FreeBSD.org if you need more help > >> > >> Thanks. Well, here are a few other questions we have: > > > > I should probably have mentioned that this is a pretty simple scenario, > > where one SVN repo gets converted to one GIT repo and the location of > > branches is well-formed and known in advance. > > > >> * Could you explain the "recurse" action? We've read through the > >> explanation on the website several times and still can't understand > >> it. > > > > I never used it, never needed to. I trust you've read this? > > http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git > > Yes, that's where the "explanation on the website" that I referred to lives.
Oh, I see. Anyway, I don't really know what it does or where you'd use it. I would encourage you to start with the simple cases and incrementally work your way to a complete ruleset. > > > > In any case, how complex is your SVN repository in terms of tags and > > branches, > > It's a royal mess; see > http://ci.boost.org/websvn/listing.php?repname=boost or > http://ci.boost.org/viewvc/boost/ if you dare. Can you, as a project, maybe come to the consensus of dropping some of that history and only restrict yourself to, say, the trunk and all release branches, but drop the dead experimental branches? > > and do you need to absolutely get this right, because you are > > switching to GIT for good, or is this more of a long-term test into > > the feasibility of the conversion? > > The former. > > >> * Is there a tool for ensuring every file state committed to SVN is > >> part of some Git commit in some Git repo produced by the system? > > > > Not to my knowledge, sorry. I only sporadically do this for the FreeBSD > > repositories, because we use SVN keywords, and it's a pain in the neck > > to get a checkout w/o them expanded. > > > >> * It seems like there could be more automation for dealing with svn > >> copies, and probably a few other tasks. Has it just turned out to be > >> not worth automating? > > > > What do you mean by svn copies? > > I mean "svn cp"s, a.k.a. branches. See the use of the --stop-on-copy > argument to svn log in the webpage you cited above. Branch copies are working just fine, but I had to nerf their use for the FreeBSD conversions, as we have a different notion of "branches" and the heuristic just doesn't apply to that repo. That said, just write a simple ruleset that gets you started and then take it from there. It's pretty simple for the FreeBSD src tree, see http://svn.freebsd.org/base/user/uqs/git_conv/freebsd.rules hth Uli _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
