[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] cvs import
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] cvs import |
Date: |
Thu, 14 Sep 2006 13:36:40 -0700 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Thu, Sep 14, 2006 at 10:05:42AM +0200, Markus Schiltknecht wrote:
> Hi,
>
> Nathaniel Smith wrote:
> >Regarding the basic dependency-based algorithm, the approach of
> >throwing everything into blobs and then trying to tease them apart
> >again seems backwards. What I'm thinking is, first we go through and
> >build the history graph for each file. Now, advance a frontier across
> >the all of these graphs simultaneously. Your frontier is basically a
> >map <filename -> CVS revision>, that represents a tree snapshot.
>
> Hm.. weren't you the one saying we should profit from the experience of
> cvs2svn?
Yes, and apparently their experience is saying that their algorithm
could be improved :-).
> Another question I'm asking myself: if it would have been that
> easy to write a sane CVS importer, why didn't cvs2svn do something like
> that?
I don't know, that's why I asked them :-).
> >I also suspect that SVN's dump format is suboptimal at the metadata
> >level -- we would essentially have to run a lot of branch/tag
> >inferencing logic _again_ to go from SVN-style "one giant tree with
> >branches described as copies, and multiple copies allowed for
> >branches/tags that are built up over time", to monotone-style
> >"DAG of tree snapshots". This would be substantially less annoying
> >inferencing logic than that needed to decipher CVS in the first place,
> >granted, and it's stuff we want to write at some point anyway to allow
> >SVN importing, but it adds another step where information could be
> >lost. I may be biased because I grok monotone better, but I suspect
> >it would be much easier to losslessly convert a monotone-style history
> >to an svn-style history than vice versa, possibly a generic dumping
> >tool would want to generate output that looks more like monotone's
> >model?
>
> Yeah, and the GIT people want the generic dump look more like GIT. And
> then there are darcs, mercurial, etc...
Well, monotone, git, and mercurial at least all share a design
heritage, and would want pretty much the same format... :-)
> >Even if we _do_ end up writing two implementations of the algorithm,
> >we should share a test suite.
>
> Sure, but as cvs2svn has another license, I can't just copy them over
> :-( I will write some tests, but if I write them in our monotone-lua
> testsuite, I'm sure nobody else is going to use them.
Duh, I forgot about the license thing :-(.
Tests could be written in a somewhat standardized way, and then we
could just have a harness to run them in our testsuite, others could
have harnesses to run them in their testsuites, while keeping the
actual test data shared.
-- Nathaniel
--
Eternity is very long, especially towards the end.
-- Woody Allen
- Re: [Monotone-devel] cvs import, (continued)
- Re: [Monotone-devel] cvs import, Nathaniel Smith, 2006/09/13
- Re: [Monotone-devel] cvs import, Jon Smirl, 2006/09/13
- Re: [Monotone-devel] cvs import, Daniel Carosone, 2006/09/13
- Re: [Monotone-devel] cvs import, Shawn Pearce, 2006/09/13
- Re: [Monotone-devel] cvs import, Daniel Carosone, 2006/09/13
- Re: [Monotone-devel] cvs import, Petr Baudis, 2006/09/15
- Re: [Monotone-devel] cvs import, Shawn Pearce, 2006/09/14
- [Monotone-devel] Re: cvs import, Lapo Luchini, 2006/09/15
- Re: [Monotone-devel] cvs import, Shawn Pearce, 2006/09/13
Re: [Monotone-devel] cvs import, Markus Schiltknecht, 2006/09/14
- Re: [Monotone-devel] cvs import,
Nathaniel Smith <=
Re: [Monotone-devel] cvs import, Markus Schiltknecht, 2006/09/14
Re: [Monotone-devel] cvs import, Michael Haggerty, 2006/09/14