monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: change_set.cc:526: invariant 'I(j != p2.end())' vio


From: Peter Simons
Subject: [Monotone-devel] Re: change_set.cc:526: invariant 'I(j != p2.end())' violated
Date: 28 Jan 2005 13:47:31 +0100

Nathaniel Smith writes:

 > But it does work. (Maybe if it really works, your case
 > should be made to work too. But that would require
 > hacking.)

I can't say I've understood the intricate details of why
what I did was "wrong", but I certainly did some wild
things while creating those branches. I'll just use the new
version and if I come across something that I think should
work but it doesn't, then I'll complain loudly. ;-)


 >> I may as well use the chance and say that I have used
 >> _every_ version control system there is [...]

 > Hmm, really? http://www.linuxmafia.com/faq/Apps/scm.html ;-)

Um, maybe not. ;-)


 >> Monotone is definitely the best of them all. You guys
 >> are doing a great job.

 > Would you mind saying a little about why you think that?

The main reason why I prefer Monotone over the other VC
systems is that it doesn't have artificial boundaries
between repositories (a.k.a. branches). If I want to
propagate changes from org.linux.kernel into
to.cryp.mail-archive, then I should be able to. Monotone
does allow me to do that, other VC systems don't.

In Darcs, you have this beautifully sophisticated merging
and sharing capabilities, but saying "Get this file from
repository A, this file from repository B, put it in C and
continue to track and merge all changes." is not impossible.
You can do it with all kinds of trickery, but I have a VC
system precisely because I don't want to do that trickery.

Another problem with Darcs is the "every checked-out copy is
a full repository" approach, IMHO. For large projects,
that's is a lot of wasted disk space.

Last but not least, I think the main feature of Darcs --
being able to commit and fetch every little change
separately -- is not what I want. Being able to fetch an
arbitrary patch and to apply it into an arbitrary repository
sounds pretty cool at first, only: I don't commit with that
kind of granularity. I simply don't care about that kind of
granularity. IMHO, meaningful commit messages and knowledge
of diff(1) serve the same purpose a lot faster than wading
through several hundred patches to find the one that you
really want.

Oh, one more minor thing: Monotone authenticates all
contents with strong cryptography. Look at my e-mail
address to see how I like that. ;-)

Having said all that, I think I should add that Darcs is a
kick-ass VC system nonetheless, and I do still use it to
allow people to submit patches to my software projects. With
Darcs, contributing to a random project works like this:

  darcs get http://cryp.to/blockio
  [screw it up]
  darcs record -m "screwed it up"
  darcs push

Now the patch is on it's way to the author via e-mail, where
all he has to do is to say

  darcs apply <the-patch

and it's in the repository. That's what I call low-overhead
submissions. ;-) Monotone used to have a similar mechanism
pre-netsync and I was quite fond of that concept. I trust
something like that will find it back into the software some
day, because being able to submit changes through the VC
system without setting anything up prior to that is cool.

Ideally, you'd be able to run public netsync servers which
accept pushes from everyone. After that, it comes down to
configuring who's signatures you accept and which ones you
don't. (Which still is a somewhat unexplored area in
Monotone by now, IMHO.) Since Monotone does authenticate the
patches with digital signatures, it can afford to allow
write access without any restrictions.

Well, I could probably go on rambling all day long. So I
better stop now. ;-)

Peter


P. S.: Of course there is one thing Darcs features that
Monotone will never ever be able to compete with: It's
written in Haskell, which is, as you know, the best
programming language there is. ;-)





reply via email to

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