Re: [Monotone-devel] Re: New project: libmtn

[Arseny Nasokin]

On Fri, Jun 30, 2006 at 11:38:40AM +0100, Bruce Stephens wrote:
> 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.
> 

FreeBSD's CVS repository is standart cvs repository. But it's too big to feet 
in 2Gb of RAM

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

I tell here not about develpment groups: GIT have superset and complex 
commands. I want provide same

> [...]
> 
> > 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.
>

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


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

There are frontends.

-- 
   Best regards,
        Arseny Nasokin