Hi, Florian Achleitner wrote: > You know I'm rather new to this topic. I've used svn and git, I know what git > plumbing is about, but I haven't used plumbing commands to write something > into git yet. So I can't tell from experience if it would be good or not, > compared to fast-import. Yes, no problem. I think the question of using fast-import or other commands is not a fundamental one. > So please explain what's the advantage/disadvantage of which design decision. > That makes it easier to get the point. The main advantages of using fast-import are: - it's faster (assuming it works correctly) :) - there are backends for version control systems other than git - remote helpers can declare the export/import capabilities to support other version control systems, instead of declaring fetch/push and supporting only git However, whatever tools you use, the immediate idea is to transfer data between a Subversion repository and a Git repository, and the problems to be solved are the same. [...] > I'm also not yet familiar with svn's internals and what properties they use > for what. > So there are several questions I simply don't have an answer for. > I know that you have discussed several issues in a huge lot of mails on this > list. I'm watching and learning currently. The svnbook at http://svnbook.red-bean.com/, the Subversion lists at <http://subversion.apache.org/mailing-lists.html>, and the #svn-dev IRC channel on freenode <http://colabti.org/irclogger/irclogger_logs/svn-dev> are the best resources I know for questions in that vein. I also learned a lot from looking at the dump format that "svnadmin dump" spits out, since it matches Subversion concepts pretty well. It is documented at https://svn.apache.org/repos/asf/subversion/trunk/notes/dump-load-format.txt Some basic design questions are covered in the thread starting at http://thread.gmane.org/gmane.comp.version-control.git/159054 > Jonathan wrote about a script "floating around". What's that? I think you mean the marks-to-notes converter. One version is at http://thread.gmane.org/gmane.comp.version-control.git/163395/focus=168514 [...] > On Monday 02 April 2012 16:30:14 Ramkumar Ramachandra wrote: >> Are you planning to extend svn-fe to do the mapping, write it as a >> separate program, or write it into the remote helper? I personally >> don't mind if the mapping is done in Perl (like in git-svn or SBL) as >> opposed to C; mapping is just parse-intensive. > > I personally don't like Perl. :p (I would use python if i need a scripting > language). > As far as I've seen, svn-fe is a 5-liner calling functions in vcs-svn/. So I > thought there is no point of piping something through svn-fe in the remote- > helper. I thought I would use those functions like svn-fe does. > I thought about vcs-svn/ being a library for svn interaction that the remote- > helper, and svn-fe, and svn-fi (?) are using. Yes, I think when Ram added vcs-svn/ to the main git repository, the intent was to make it a library that some git-remote-svn.c could use directly. [...] > On Monday 02 April 2012 15:57:00 Jonathan Nieder wrote: >> The word "new" makes me worried that you'd be throwing away whatever >> work already exists. :) > > Probably I missed something. > But all I've seen that is directly a remote-helper is a bash script which > basically calls a pipeline from svnrdump | svn-fe | fast-import [2]. > I'm not planning to write a longer program in bash. (I personally use bash > only for things that fit on one terminal height). > > Bash and Perl are not my favourites ;) I think that's fine. It's a prototype, and it has -alpha in its name to make sure people understand there are no compatibility guarantees which avoids constraining us. What I was more worried about is throwing away discoveries made in the previous design and starting over. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html