All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Cc: git@vger.kernel.org, David Michael Barr <davidbarr@google.com>,
	Andrew Sayers <andrew-git@pileofstuff.org>,
	Dmitry Ivankov <divanorama@gmail.com>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	Sam Vilain <sam@vilain.net>
Subject: Re: GSOC remote-svn: branch detection
Date: Fri, 3 Aug 2012 11:17:28 -0700	[thread overview]
Message-ID: <20120803181728.GA21745@copier> (raw)
In-Reply-To: <12682331.q6WHVv9EKU@flomedio>

Hi,

Florian Achleitner wrote:

> Two approaches:
> 1. Import linearly and split later:
> One idea is to import from svn linearly, i.e. one revision on top of it's 
> predecessor, like now, and detect and split branches afterwards. The svn 
> metadata is stored in git notes, so the required information would be 
> available.
> + allows recovery, because the linear history is always here.
> + it's easier to peek around in the git history than in the svn dump during 
> import to do the branch detection.
> - requires creation of new commits in the branch detection stage.
> - this results in double commits and awkward history, linear vs. branched.

I don't think you've captured the real pros and cons here.

+ Divides responsibility between a component that fetches and a component
that splits branches, making for easier debugging, independent refactoring
of components, reuse in other contexts (e.g., splitting out branches in
other similar VCSen, etc)

- Divides responsibility between a component that fetches and a component
that splits branches, which is tricky because it involves designing an
interface between them and documenting it.  And maybe a different
interface would be better.

There are also performance and history-clarity ramifications as you've
mentioned, but they do not seem as important.

Hope that helps,
Jonathan

> 2. Split during import:

  reply	other threads:[~2012-08-03 18:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-03  9:43 GSOC remote-svn: branch detection Florian Achleitner
2012-08-03 18:17 ` Jonathan Nieder [this message]
2012-08-04  6:40   ` Dmitry Ivankov
2012-08-04 18:23   ` Ramkumar Ramachandra
2012-08-07 21:26     ` Florian Achleitner

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=20120803181728.GA21745@copier \
    --to=jrnieder@gmail.com \
    --cc=andrew-git@pileofstuff.org \
    --cc=artagnon@gmail.com \
    --cc=davidbarr@google.com \
    --cc=divanorama@gmail.com \
    --cc=florian.achleitner.2.6.31@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sam@vilain.net \
    /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.