git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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).