[Kde-scm-interest] New message: Re: svn2git for Boost

Ulrich Spörlein uqs at FreeBSD.org
Wed Jan 2 20:37:13 UTC 2013


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


More information about the Kde-scm-interest mailing list