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
next prev parent 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).