Re: [Monotone-devel] Fwd: VCS comparison table

[Brian May]

>>>>> "Ulf" == Ulf Ochsenfahrt <address@hidden> writes:

    Ulf> As almost everyone who's been in the os dev game for a couple
    Ulf> of years, I started out with CVS. I then discovered

I thought everyone started with RCS! ;-)

Ok, same thing, different perspective.

Initially, when I started, the working model for RCS was to lock the
file before editing it. This guaranteed collisions didn't occur, back
in a time when collisions where evil and scary things that must be
avoided at all costs.

Then came the new CVS model where two or more people could edit the
same file at the same time. It was up to the editor to ensure his
working directory was up-to-date with the repository before doing a
commit though, or you would get errors. In a disorganised organisation
I use to work for I had problems with other people not merging in my
changes correctly or doing an update with the file still loaded in a
text editor and accidently reverting my changes in the process.

An alternative version is what wikipedia uses. If you go to an old
version and commit, it acts like a revert and commits the old version
as the latest revision. Kind of confuses people at time.  For example,
one time Slashdot linked to a specific version of a wikipedia page -
one that contained vandalism. Readers didn't realize it was an old
version and started editing it to remove the vandalism, reverting all
other recent changes in the process (and often adding back parts of
the vandalism).

And finally we have come to the day of distributed systems. One key
benefit I see with monotone over other solutions I have used (tla, baz
and probably bzr) is the entire history gets replicated - so there is
no requirement that I have to run a separate server for eternity if I
want to contribute changes to a project.

Unfortunately, this transition in working models is not all good. For
example, somebody I know works for a company stores that shared
Microsoft Word documents in a subversion repository (argghh! Word
can't cope with the complexity! Yes, there probably would have been
numerous other solutions). As nobody has written a merge method for
Word files (that I know of anyway), especially word files this complex
(numerous cross references between files), the only method that works
is the old file locking approach. Apparently subversion supports this
(I didn't think it did). Just as long as nobody breaks the
locks... (has happened).

Oh... did I mention disconnected operations from laptops is also a
requirement? Arghhh!

Then again, maybe there are some problems that can't be solved with
VCS alone. I think locking and disconnected operations are
incompatible.

    Ulf> I was looking for something that supported true distributed
    Ulf> operation, windows, and disconnected operation, and most

I wasn't looking for a alternative system. bzr was perfect. Then some
moron (!) showed me monotone, and ...

    Ulf> ... when I took a look at the monotone tutorial, I was an
    Ulf> instant convert. It solves all the gripes I had with tla/baz
    Ulf> and it has a beautifully simple and robust history
    Ulf> model. Optimal support for disconnected
    Ulf> operations. Distributed operation is what it does. And the
    Ulf> history model (tutorial) explains the distributed operation
    Ulf> very intuitively. I was a bit sceptical about the sqlite
    Ulf> backend, but that turns about to be a good decision: sqlite
    Ulf> makes a very mature impression, and having just a single file
    Ulf> is a good thing for backup/migration (move to a new machine
    Ulf> every 1-1.5 years) purposes.

Also the reliance on sha1 numbers so frequently requires a new mind
twist.

I am still concerned that sometime in the future (after extensive use)
two sha1 numbers for two separate items might accidently (and I mean
accidently) collide - but maybe when this happens we will already be
switching to an alternative anyway...

    Ulf> Oh, and the discussion on that thread tells me that I was
    Ulf> right to not go to bzr, I think that Linus is absolutely
    Ulf> right about the rev number issue, plus I can't see a lot of
    Ulf> advantages in a plugin architecture. For a rcs that is, in
    Ulf> general, plugins make a lot of sense. But not if I want an
    Ulf> extremely stable low-level tool.

I got lost in the rev number issue (read: didn't have time to digest
the arguments properly), and really couldn't see the problem with
plugins. Besides, with the lua hooks, you could argue that monotone
has a plugin architecture...

    Ulf> And here's my monotone wishlist: - eclipse integration - HTTP
    Ulf> support for pull (I don't particularly like the fact that I
    Ulf> have to have another service / open port on my server.)  -

I don't think this is all bad. I especially trust apache - although in
practise I suspect a lot of security breaches I have seen are due to
badly written PHP code...

You can also access a remote repository via ssh (I couldn't find this
being mentioned in the tutorial or anywhere else in the documentation
though).

    Ulf> someone fix the DOS vulnerability in mtn serve - being able

What DOS vulnerability is this?

    Ulf> to pull just a part of the archive (one of my project is 20
    Ulf> MB and growing and pulling that over a dial-up line is bad,
    Ulf> just bad) - even if that means that you can't perform all
    Ulf> operations locally

This could be a can of worms.

Are you saying that the initial download is a problem, or the pull
operations too?
-- 
Brian May <address@hidden>