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

[rghetta]

Hi all.
I'm a long time lurker of this list, out of personal interest in monotone.
Recently my company began an evaluation of SCM systems aimed at
replacing our current tool, M$ SourceSafe, with something better (almost
everything is better, scm-wise).
GUI and MSDEV integration are essential in our environment, so monotone
wasn't really considered, but its other properties are so interesting
that I still made a limited evaluation.
I still hope my 2cents will be useful, even if biased towards our
working environment and coming now that monotone is in "kernel mode" ;)

Our situation:
We have about 40 people (about half are programmers) in three sites,
plus an handful of developers physically located to customer's sites
connected via VPN.
Our primary development platform is Windows, using M$ Visual Studio
(C++/MFC), but with some projects on linux.
A full mainline working copy right now is about 90MB (200 dirs, 7000
files), growing 30% every year.

- Some timings (P4 2.8Ghz, 512MB, XP SP2, XP SP2)
Add:                    58"
Status without commit:  2' 18"
Commit:                 9'
        after about 2' outputs "beginning commit on branch ..."
Update:                 2' 88"
Resulting database size: 33MB

Somewhat surprisingly, monotone performance is survivable for add/commit
(nine minutes is not fast, but you don't add 7000 files every day) but
horrible for status/update.
Monotone needs almost three minutes just to discover that my working
copy is current (by contrast other scm resolve very quickly)
I initially commited without the branch name: monotone worked two
minutes before complaining, instead of checking immediately.
On the same vein, monotone asked my passphrase only just before
committing, instead of asking right after the commit command.
Before starting the database commit, I/O was almost not existent, cpu
usage no more than 50% and memory use was small (~8MB) suggesting that
there is room for some agressive caching.
I suspect the <50% cpu usage is an artifact of XP view of
hyperthreading, but this could also come from a suboptimal memory
allocation strategy.

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

- Problems
GUI/IDE integration: we need both; OTH probably someone sooner or later
will implement them.

Speed: right now is a problem, but the emphasis has been on correctness,
thus perhaps monotone could gain speed really quickly  (ahem)

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 ?

Commit granularity:  the restrictions support is a giant leap forward,
but, if I am right, you can restrict only a single filespec, not a list
of specs (or a file containing the specs).
This feature is more useful when using a GUI, because picking just some
sparse files is far easier than specifing a long list of filespec on cmd
line.

Other, much minor, gripes follows:
In our environment, we need a finer grained authorization control, while
monotone "trust" properties play a much smaller role than in a OSS project.
From a project manager point of view, the reporting ability of monotone
is currently limited, unless you go directly at the SQL level.
Speaking of SQL, how dependent is monotone on SQLite ?
Silly as it seems, *optionally* running a repo with Oracle or DB2 as
backend would boost monotone acceptancy to management.

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