Re: [Monotone-devel] monotone evaluation in commercial project [long]

[Nathaniel Smith]

On Fri, Apr 08, 2005 at 04:57:54PM +0200, rghetta wrote:
> I still hope my 2cents will be useful, even if biased towards our
> working environment and coming now that monotone is in "kernel mode" ;)

Oh, definitely.  The kernel's a big project, but only one, and in
some ways not at all representative; we care about other projects too
:-).

> - Mapping monotone to our working environment
> Monotone working model is very interesting for us: as an example, when a
> group of developer need to implement a new feature, they can just create
> a newer branch on their local repos (or even a new local repo) and sync
> just the participating repos, without polluting the "official",
> centralized, main repo.
> Other SCM require server support for branches, adding overhead without a
> real benefit, since after completing the feature the "working branch" is
> merged and never looked back.
> Benefit for customer-located developers are obvious.

I'm not sure why "polluting" the centralized repo is a bad thing?
Monotone certainly allows the developers to sync with each other
directly, which can be very handy if they don't have a connection to
the main repo because of firewalls or whatever, but surely you want a
central copy of their work-in-progress when possible, for backups and
all that kind of thing?

Also note that when the branch is merged back in, you will have to
push the branch to the central repo.  This is partly just because of
technical limitations, but you may not mind the technical limitations
so much the first time you discover after merging that someone had
uncommitted work on the working branch, that you need to relate to the
rest and merge in too :-)

> Repository size: if we were to use monotone for development, perhaps
> this would be our biggest problem.
> Now our VSS database is well over the GB mark and having a monotone db
> of a similar size would be a real PITA, esp. if you like to have
> multiple local repos.
> A possible solution would be the ability to make a shallow copy of the
> central repo, where by "shallow" I mean the smallest revision tree who
> could preserve branch heads without throwing away the common ancestor
> needed for merging.
> For a single branch this should be more or less only the changes from
> the latest merging, right ?

This is more complicated than it may seem.  There are all sorts of
really nasty edge cases.  Note that in your scheme, there is a problem
if someone every commits a revision that's a child of some old
revision -- new heads can arrive at any time, and there is no
guarantee that they are descendended from the old heads.  We're
working on this kind of thing, but it takes some care to get right.

> In our environment, we need a finer grained authorization control, while
> monotone "trust" properties play a much smaller role than in a OSS project.

Yes, monotone's current trust model is basically just a stand-in for
the proper thing that we need to implement (and have partially
designed).  It's a big piece of design and code, though, and the focus
recently has been on lots of smaller polish things.

> All in all, monotone confirms its potential: some commercial SCMs I've
> evaluated fared much much worse.

Thank you.

-- Nathaniel

-- 
In mathematics, it's not enough to read the words
you have to hear the music