git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sam Vilain <sam@vilain.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	David Michael Barr <david.barr@cordelta.com>,
	Sverre Rabbelier <srabbelier@gmail.com>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Daniel Shahaf <d.s@daniel.shahaf.name>,
	Eric Wong <normalperson@yhbt.net>
Subject: Re: [GSoC update extra!] git-remote-svn: Week 8
Date: Wed, 30 Jun 2010 13:51:05 +1200	[thread overview]
Message-ID: <1277862665.23613.8.camel@wilber> (raw)
In-Reply-To: <20100624180752.GA1642@burratino>

On Thu, 2010-06-24 at 13:07 -0500, Jonathan Nieder wrote:
> operation.  In other words, it needs the tree for
> http://path/to/some/svn/root/branches@r11.  This does not correspond
> to a single git tree, since the content of each branch has been given
> its own commit.

I wrote at length about this near the beginning of the project;
essentially, figuring out whether particular paths are roots or not is
not defined, as SVN does not distinguish between them (a misfeature
cargo culted from Perforce).  It becomes a data mining problem, you have
this scattered data, and you have to find a history inside.

As I recommended before, it probably makes more sense to keep a "remote
tracking" branch which mirrors the *entire* repository, and sort out
efficient ways to convert SVN revision paths like the above into tree
IDs.

I consider it very important to separate the data import and tracking
stage from the data mining stage.

Once the data mining stage is well solved, then it makes sense to look
at ways that a tracking branch which only tracks a part of the
Subversion repository can be achieved.  In the simple case, where no
repository re-organisation or cross-project renames have occurred it is
relatively simple.  But in general I think this is a harder problem,
which cannot always be solved without intervention - and so not
necessary to be solved in short-term milestones.  As you are
discovering, it is a can of worms which you avoid if you know you always
have the complete SVN repository available.

Sam

  parent reply	other threads:[~2010-06-30  1:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-24 13:33 [GSoC update extra!] git-remote-svn: Week 8 Ramkumar Ramachandra
2010-06-24 17:39 ` Jonathan Nieder
2010-06-24 18:07   ` Jonathan Nieder
2010-06-24 21:32     ` Eric Wong
2010-06-30  1:51     ` Sam Vilain [this message]
2010-06-30 12:45       ` Ramkumar Ramachandra
2010-07-01  3:38         ` Sam Vilain
2010-06-30  2:20   ` Sam Vilain

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=1277862665.23613.8.camel@wilber \
    --to=sam@vilain.net \
    --cc=artagnon@gmail.com \
    --cc=d.s@daniel.shahaf.name \
    --cc=david.barr@cordelta.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=normalperson@yhbt.net \
    --cc=spearce@spearce.org \
    --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 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 NNTP newsgroup(s).