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 11:38:40 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Arseny Nasokin <address@hidden> writes:

[...]

> Yes, about after 300 branches commited in (about 500'000
> revisions). The message from ZSH: killed

Right.  There could be bugs there; however, converting from CVS to
anything (except subversion) isn't a process with an obviously right
outcome.

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.

[...]

> Git is only for one developer :(

Well, Linus designed it for himself, so the features are what he
wanted.

More generally, it's intended to be used locally, with each developer
having their own copy of the repository.  That's not specific to git,
though: many systems work that way (including monotone, of course).

[...]

> design lacks: I can't disapprove revision for _one_ file from it. or
> it is possible create revisions, which are complex, not simple.

By the first, do you mean you want to revert the changes in one file
from a revision, while keeping the rest?

It's true that you can't directly do that, but that's not a lack,
that's a necessary property of versioning based on whole trees,
combined with the kind of distribution that monotone supports.  (With
darcs, one can fix a patch by unrecording it, then recording it again
without the changes to one file; the same is possible in monotone,
provided the revision has no descendents.  In both cases things'll
break (or at least be confusing) if the original change has been
distributed.)

And the second, I guess you mean replacing several revisions by one?
Or some way to group several revisions?  Those have been talked about,
but the distributed nature of monotone makes it tricky, and it's not
clear that there's that much need.

> backend migrating: It's too hard write simple frontend for migrating
> from {CVS, SVN,...} to monotone and back.

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).

[...]





reply via email to

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