From: Stephen Bash <bash@genarts.com>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Matt Stump <mstump@goatyak.com>,
git@vger.kernel.org, David Barr <david.barr@cordelta.com>,
Tomas Carnecky <tom@dbservice.com>,
Ramkumar Ramachandra <artagnon@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)
Date: Fri, 15 Oct 2010 10:50:46 -0400 (EDT) [thread overview]
Message-ID: <2196050.492435.1287154246295.JavaMail.root@mail.hq.genarts.com> (raw)
In-Reply-To: <AANLkTi=PwLmKSb_gF=k+xVSZfM1CDCFZFZdR7pLgh6t6@mail.gmail.com>
> Thanks for the very interesting read. It seems like a (very) long
> pipeline though, I wonder how we can make this not only easier, but
> also more streamlined for git-remote-svn.
The process can certainly be streamlined. As is often the case, this process was created via the "just make it work" mentality (and a barely passable knowledge of git). Now that I'm a little more comfortable with git and it's basic objects, I think I could probably create a new process that does a single pass through the svn-fe created repository and creates a new repository with the correct history (and some other nice features that come with any 2.0).
But I'm also looking at this from a one-time conversion view. I had a couple of conversations with Ram that showed me my point of view is very narrow compared to the larger git-remote-svn effort...
> Do you have any suggestions
> on how you would prefer this to be done in git-remote-svn? (Main
> advantage for git-remote-svn might be that we can use git notes to
> store commit conversion information, instead of having to mine commit
> messages.)
I think using notes is a better way to associate conversion information with commits, but I would probably still end up mining the notes to create some sort of svn to git mapping... Correct me if I'm wrong, but I don't see how notes would help me get from an svn rev to a git sha (a common practice for tickets and wiki links in our organization). The latter is more a job for tags, and while that would be possible, that more than doubles the number of objects in the repository (I have a good percentage of SVN revs that turned into multiple git commit objects).
But otherwise, my suggestions are (unfortunately) rather naive. "Make it work like git-svn, but faster" :) I can offer the warning to watch out for cross-branch (subdirectory/file) copies; we had a lot of those in our SVN repository, and I still don't know if there's anyway in Git to represent that operation... And obviously even if I did have/use the svn merge information, svn merges don't map directly to git merges... but I'm guessing I'm not saying anything you haven't already thought about.
I guess after that I should add that I'm happy to help, I'm just not sure where my experience maps to the on going effort.
Thanks,
Stephen
next prev parent reply other threads:[~2010-10-15 14:51 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-13 15:44 Speeding up the initial git-svn fetch Matt Stump
2010-10-13 16:02 ` Stephen Bash
2010-10-13 17:47 ` Matt Stump
2010-10-13 18:18 ` Stephen Bash
2010-10-14 16:22 ` Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch) Stephen Bash
2010-10-14 16:34 ` Jonathan Nieder
2010-10-14 20:07 ` Sverre Rabbelier
2010-10-15 14:50 ` Stephen Bash [this message]
2010-10-15 23:39 ` Sverre Rabbelier
2010-10-16 0:16 ` Stephen Bash
2010-10-17 2:25 ` Sverre Rabbelier
2010-10-17 3:33 ` David Michael Barr
2010-10-18 5:17 ` Ramkumar Ramachandra
2010-10-18 7:31 ` Jonathan Nieder
2010-10-18 16:38 ` Ramkumar Ramachandra
2010-10-18 16:46 ` Sverre Rabbelier
2010-10-18 16:56 ` Jonathan Nieder
2010-10-18 17:16 ` Ramkumar Ramachandra
2010-10-18 17:18 ` Sverre Rabbelier
2010-10-18 17:28 ` Jonathan Nieder
2010-10-18 18:10 ` Sverre Rabbelier
2010-10-18 18:13 ` Jonathan Nieder
2010-10-18 18:20 ` Sverre Rabbelier
2010-10-18 18:25 ` Jonathan Nieder
2010-10-18 18:35 ` Sverre Rabbelier
2010-10-18 19:33 ` Jonathan Nieder
2010-10-19 3:08 ` Ramkumar Ramachandra
2010-10-19 0:40 ` Stephen Bash
2010-10-19 1:42 ` Stephen Bash
2010-10-19 6:42 ` Ramkumar Ramachandra
2010-10-19 13:33 ` Stephen Bash
2010-10-19 14:28 ` David Michael Barr
2010-10-19 14:57 ` Stephen Bash
2010-10-20 8:39 ` Will Palmer
2010-10-20 11:59 ` Jakub Narebski
2010-10-20 13:42 ` Will Palmer
2010-10-20 20:44 ` Jakub Narebski
2010-10-21 1:54 ` mrevilgnome
2010-10-21 8:16 ` Jakub Narebski
2010-10-21 13:49 ` Stephen Bash
2010-10-21 9:08 ` Will Palmer
2010-10-21 14:00 ` Stephen Bash
2010-10-21 18:37 ` Jakub Narebski
2010-10-21 21:27 ` Stephen Bash
2010-10-21 22:49 ` Jakub Narebski
2010-10-21 23:26 ` Stephen Bash
2010-10-22 10:38 ` Jakub Narebski
2010-10-21 15:52 ` Jakub Narebski
2010-10-21 16:16 ` Jonathan Nieder
2010-10-20 14:05 ` Ramkumar Ramachandra
2010-10-20 14:21 ` Stephen Bash
2010-10-20 16:56 ` Ramkumar Ramachandra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2196050.492435.1287154246295.JavaMail.root@mail.hq.genarts.com \
--to=bash@genarts.com \
--cc=artagnon@gmail.com \
--cc=david.barr@cordelta.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mstump@goatyak.com \
--cc=srabbelier@gmail.com \
--cc=tom@dbservice.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.