From: Phil Hord <phil.hord@gmail.com>
To: Andrew Sayers <andrew-git@pileofstuff.org>
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>,
Sam Vilain <sam@vilain.net>, David Barr <davidbarr@google.com>
Subject: Re: Approaches to SVN to Git conversion
Date: Wed, 7 Mar 2012 17:33:39 -0500 [thread overview]
Message-ID: <CABURp0pLnMdFVgQ2+S_rW-KEjUBjKbEbMepEdPUkRJD+JQ_Ehg@mail.gmail.com> (raw)
In-Reply-To: <4F5690FB.9060800@pileofstuff.org>
On Tue, Mar 6, 2012 at 5:34 PM, Andrew Sayers
<andrew-git@pileofstuff.org> wrote:
> This is quite close to the implementation I've got. The SVN exporter
> runs in two stages:
>
> In the first stage, the script treats any non-blacklisted file as a
> marker file, but only looks for trunk branches. It looks all through
> the history, traces back through the copyfroms, and tries to find the
> original directory associated with the file. Usually it decides that
> the only branch without a copyfrom is /trunk. Searching just for trunks
> with this weak heuristic makes it much easier to hand-verify the result.
>
> In the second stage, the script looks through the history again, tracing
> the copies of known branches in a slightly less clever way than
> described in my previous e-mail. There's no need for marker files this
> time round, as we just assume any `svn cp /trunk
> /directory/not/within/a/branch` is a new branch. In my experiments this
> has been a pretty solid way of detecting branches without too much human
> input - I might be missing something (or have mis-explained something),
> but I'd be interested to hear examples of where this would go wrong.
I think what you're describing would work perfectly for my weird svn
repo. I have branches named like this:
branches/developer/hordp/foo
branches/developer/hordp/bar
etc.
Since these were created with 'svn cp' originally, they would be
properly considered branches by your algorithm, right? If so,
sweet!
> Having said that, here's a dodgy example I'd like to pre-emptively defend:
>
> svn add tronk
> svn ci -m "Created trunk" # r1
> svn cp tronk trunk
> svn ci -m "D'oh" # r2
> svn rm tronk
> svn add trunk/markerFile.txt
> svn ci -m "Double d'oh!" # r3
>
> You could argue that the correct branch history description for the
> above would be:
>
> In r3, create branch "trunk"
>
> In other words, ignore everything that happened before the marker file
> was created. However, I would argue the following representation is
> more correct:
>
> In r1, create branch "tronk"
> In r2, create branch "trunk" from "tronk" r1
> In r3, delete branch "tronk"
>
I prefer your interpretation. It doesn't look dodgy at all.
Phil
next prev parent reply other threads:[~2012-03-07 22:34 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
2012-03-07 22:33 ` Phil Hord [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABURp0pLnMdFVgQ2+S_rW-KEjUBjKbEbMepEdPUkRJD+JQ_Ehg@mail.gmail.com \
--to=phil.hord@gmail.com \
--cc=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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).