All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Sayers <andrew-git@pileofstuff.org>
To: Sam Vilain <sam@vilain.net>
Cc: Nathan Gray <n8gray@n8gray.org>, Stephen Bash <bash@genarts.com>,
	Jonathan Nieder <jrnieder@gmail.com>, Jeff King <peff@peff.net>,
	git@vger.kernel.org, Sverre Rabbelier <srabbelier@gmail.com>,
	Dmitry Ivankov <divanorama@gmail.com>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	David Barr <davidbarr@google.com>
Subject: Re: Approaches to SVN to Git conversion
Date: Wed, 07 Mar 2012 20:28:58 +0000	[thread overview]
Message-ID: <4F57C50A.9010701@pileofstuff.org> (raw)
In-Reply-To: <4F5780F0.5080901@vilain.net>

On 07/03/12 15:38, Sam Vilain wrote:
> On 3/6/12 2:34 PM, Andrew Sayers wrote:
>> I've now added a bit of documentation and uploaded my code to github:
>> https://github.com/andrew-sayers/Proof-of-concept-History-Converter
>>
>> I haven't attached it here because the code isn't at a stage where it
>> would be useful to review line-by-line.  Comments are welcome if you
>> really want to though :)
> 
> I just took a look at your readme—did you consider writing the tool to
> work against an svn-fe import, rather than using SVN::Dump? Do you think
> it could be adjusted to be like that?

I did consider writing svn-branch-export.pl against a branch created by
svn-fe, but right now it doesn't provide enough information to do a good
job (e.g. copyfrom properties).  I understand that support is in the
works, but this project is more about getting a scrappy end-to-end
solution so we can see what the issues are (is there any demand for
DVCS-neutral SVN history export?  What are the hard cases and how do you
represent them?).  I'm keen to make sure that documentation and tests
are done in such a way that a future git-based exporter could use them
without relying on any of the actual code.

I also considered writing git-branch-import.pl against the raw svn-fe
output.  As well as the technical issues with this approach, I felt like
these were better tackled as orthogonal problems.  Producing an accurate
representation of the SVN history is a very different problem to
producing a user-friendly representation, and separating those concerns
seems like it will make life easier down the line.  For example, a
user-friendly representation might convert svn:ignore properties to
.gitignore files, but that would make bidirection hard to implement
without an accurate representation in the middle.

	- Andrew

  reply	other threads:[~2012-03-07 20:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-03 12:27 [RFC] "Remote helper for Subversion" project David Barr
2012-03-03 12:41 ` David Barr
2012-03-04  7:54   ` Jonathan Nieder
2012-03-04 10:37     ` David Barr
2012-03-04 13:36       ` Andrew Sayers
2012-03-05 15:27         ` Approaches to SVN to Git conversion (was: Re: [RFC] "Remote helper for Subversion" project) Stephen Bash
2012-03-05 23:27           ` Approaches to SVN to Git conversion Andrew Sayers
2012-03-06 14:36             ` Stephen Bash
2012-03-06 19:29           ` Approaches to SVN to Git conversion (was: Re: [RFC] "Remote helper for Subversion" project) Nathan Gray
2012-03-06 20:35             ` Stephen Bash
2012-03-06 23:59               ` [spf:guess] " Sam Vilain
2012-03-07 22:06                 ` Andrew Sayers
2012-03-07 23:15                   ` [spf:guess,iffy] " Sam Vilain
2012-03-08 20:51                     ` Andrew Sayers
2012-03-06 22:34             ` Approaches to SVN to Git conversion Andrew Sayers
2012-03-07 15:38               ` Sam Vilain
2012-03-07 20:28                 ` Andrew Sayers [this message]
2012-03-07 22:33               ` Phil Hord
2012-03-07 23:08               ` Nathan Gray
2012-03-07 23:32                 ` Andrew Sayers
2012-03-04 16:23       ` [RFC] "Remote helper for Subversion" project Jonathan Nieder
2012-03-27  3:58     ` 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=4F57C50A.9010701@pileofstuff.org \
    --to=andrew-git@pileofstuff.org \
    --cc=artagnon@gmail.com \
    --cc=bash@genarts.com \
    --cc=davidbarr@google.com \
    --cc=divanorama@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=n8gray@n8gray.org \
    --cc=peff@peff.net \
    --cc=sam@vilain.net \
    --cc=srabbelier@gmail.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.