monotone-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]