monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: New project: libmtn


From: Bruce Stephens
Subject: [Monotone-devel] Re: New project: libmtn
Date: Fri, 30 Jun 2006 15:28:56 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Arseny Nasokin <address@hidden> writes:

> On Fri, Jun 30, 2006 at 11:38:40AM +0100, Bruce Stephens wrote:

[...]

>> So for any algorithm I'd expect it to work well on some CVS
>> repositories and horribly on others.  So maybe the FreeBSD repository
>> is unlike those for the monotone code was designed for.
>> 
>
> FreeBSD's CVS repository is standart cvs repository. But it's too
> big to feet in 2Gb of RAM

Sure, but CVS records things for each file separately (including
things like tags and branch information).  Monotone (and most other
modern systems) records such things for whole trees.

So for some CVS repositories (most, probably), there can be no
monotone repository that represents what's in the CVS repository.
It's simply not possible, because CVS can represent things that can't
be represented by monotone.  (Other systems have the same problem; the
obvious exception is subversion, which also does things for each file
separately---subversion lacks CVS's modules, so it can't (generally)
represent those.)

Now, some CVS repositories will branch and tag files in whole trees
(and at the same time); if they do it consistently, then such a
history would be representable in monotone (and other systems).

And converting such a repository ought to be doable with finite
(smallish) memory, although you'd probably need to use a multiphase
approach like cvs2svn (writing each phase to file).  My guess is that
such consistent CVS repositories are pretty rare.

[...]

> It's good, that monotone save many patches at one revision, but it's
> unpossible remove some from it, or patch back-diff :(

There's nothing preventing you from updating a workspace to the last
revision, then replacing the file with a copy from a previous
workspace, and then committing that.  (Nathaniel has suggested a "mtn
revert --revision <rev> <path>" for the reverting of a file (or files)
to a different revision.)

In general, you can certainly commit revisions that contain only
changes to a single file.  You can't change a previously committed
revision (beyond "db kill_rev_locally"), but that's a feature that's
more or less forced by distribution.

>> Yes, but I'm not sure that's monotone's fault: the problem itself is a
>> hard one (or at least not a clearly defined one---different people
>> might reasonably have a different idea of exactly what they'd want
>> from such a thing).
>
> There are frontends.

Of course.  The problem is that CVS can represent (and does,
routinely) things that monotone can't.  If you want to map CVS
accurately (ignoring CVS modules, which nothing except CVS seems to
support), then you'll have to use subversion, I think.

In some ways subversion is even worse: in subversion you can create a
branch or tag (or what are conventionally called branches or tags) by
copying arbitrary revisions of arbitrary sets of files.  monotone
can't represent that directly.  Nor should it try, I think.




reply via email to

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