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
> I never used it, never needed to. I trust you've read this?
Yes, that's where the "explanation on the website" that I referred to lives.
> In any case, how complex is your SVN repository in terms of tags and
It's a royal mess; see
if you dare.
> 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?
>> * 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.