git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: Markus Schiltknecht <markus@bluegap.ch>,
	Martin Langhoff <martin.langhoff@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	monotone-devel@nongnu.org, dev@cvs2svn.tigris.org
Subject: Re: cvs import
Date: Thu, 14 Sep 2006 07:36:56 +0200	[thread overview]
Message-ID: <4508EA78.5030001@alum.mit.edu> (raw)
In-Reply-To: <9e4733910609131438n686b6d72u4d5799533c7473d7@mail.gmail.com>

Jon Smirl wrote:
> On 9/13/06, Markus Schiltknecht <markus@bluegap.ch> wrote:
>> Martin Langhoff wrote:
>> > On 9/14/06, Jon Smirl <jonsmirl@gmail.com> wrote:
>> >> Let's copy the git list too and maybe we can come up with one importer
>> >> for everyone.

That would be great.

> AFAIK none of the CVS converters are using the dependency algorithm.
> So the proposal on the table is to develop a new converter that uses
> the dependency data from CVS to form the change sets and then outputs
> this data in a form that all of the backends can consume. Of course
> each of the backends is going to have to write some code in order to
> consume this new import format.

Frankly, I think people are getting the priorities wrong by focusing on
the format of the output of cvs2svn.  Hacking a new output format onto
cvs2svn is a trivial matter of a couple hours of programming.

The real strength of cvs2svn (and I can say this without bragging
because most of this was done before I got involved in the project) is
that it handles dozens of peculiar corner cases and bizarre CVS
perversions, including a good test suite containing lots of twisted
little example repositories.  This is 90% of the intellectual content of
cvs2svn.

I've spent many, many hours refactoring and reengineering cvs2svn to
make it easy to modify and add new features.  The main thing that I want
to change is to use the dependency graph (rather than timestamps tweaked
to reflect dependency ordering) to deduce changesets.  But I would never
think of throwing away the "old" cvs2svn and starting anew, because then
I would have to add all the little corner cases again from scratch.

It would be nice to have a universal dumpfile format, but IMO not
critical.  The only difference between our SCMs that might be difficult
to paper over in a universal dumpfile is that SVN wants its changesets
in chronological order, whereas I gather that others would prefer the
data in dependency order branch by branch.

I say let cvs2svn (or if you like, we can rename it to "cvs2noncvs" :-)
) reconstruct the repository's change sets, then let us build several
backends that output the data in the format that is most convenient for
each project.

Michael

  reply	other threads:[~2006-09-14  5:37 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <45084400.1090906@bluegap.ch>
2006-09-13 19:01 ` cvs import Jon Smirl
2006-09-13 20:41   ` Martin Langhoff
2006-09-13 21:04     ` Markus Schiltknecht
2006-09-13 21:15       ` Oswald Buddenhagen
2006-09-13 21:16       ` Martin Langhoff
2006-09-14  4:17         ` Michael Haggerty
2006-09-14  4:34           ` Jon Smirl
2006-09-14  5:02             ` Michael Haggerty
2006-09-14  5:21               ` Martin Langhoff
2006-09-14  5:35                 ` Michael Haggerty
2006-09-14  5:30               ` Jon Smirl
2006-09-14  4:40           ` Martin Langhoff
2006-09-13 21:05     ` Markus Schiltknecht
2006-09-13 21:38       ` Jon Smirl
2006-09-14  5:36         ` Michael Haggerty [this message]
2006-09-14 15:50           ` Shawn Pearce
2006-09-14 16:04             ` Jakub Narebski
2006-09-14 16:18               ` Shawn Pearce
2006-09-14 16:27               ` Jon Smirl
2006-09-14 17:01                 ` Michael Haggerty
2006-09-14 17:08                   ` Jakub Narebski
2006-09-14 17:17                   ` Jon Smirl
2006-09-15  7:37             ` Markus Schiltknecht
2006-09-16  3:39               ` Shawn Pearce
2006-09-16  6:04                 ` Oswald Buddenhagen
2006-09-16  6:21                 ` Nathaniel Smith
2006-09-13 22:52 ` Nathaniel Smith
2006-09-13 23:21   ` Daniel Carosone
2006-09-13 23:52     ` [Monotone-devel] " Daniel Carosone
2006-09-13 23:42   ` Keith Packard
2006-09-14  0:32     ` Nathaniel Smith
2006-09-14  0:57       ` [Monotone-devel] " Jon Smirl
2006-09-14  1:53         ` Daniel Carosone
2006-09-14  2:30           ` [Monotone-devel] " Shawn Pearce
2006-09-14  3:19             ` Daniel Carosone
2006-09-14 21:57           ` [Monotone-devel] " Petr Baudis
2006-09-14 22:04             ` Shawn Pearce
2006-09-14  2:35     ` Shawn Pearce
2009-02-16  9:17 CVS import Ferry Huberts (Pelagic)

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=4508EA78.5030001@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=dev@cvs2svn.tigris.org \
    --cc=git@vger.kernel.org \
    --cc=jonsmirl@gmail.com \
    --cc=markus@bluegap.ch \
    --cc=martin.langhoff@gmail.com \
    --cc=monotone-devel@nongnu.org \
    /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).