[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