Re: Is monotone dead, or is there a path forward?

[Brian May]

CooSoft Support <support@coosoft.plus.com> writes:

> I loved using Monotone and agree that the merging in mtn is far superior 
> to the run of the mill merging you get with git (after all it's site did 
> refer to it as a stupid/dumb content tracker). In fact mtn's merging is 
> the best I've ever used. I liked the fact that changesets were stored 
> efficiently as compressed deltas in mtn as well. However the world has 
> moved on and the projects that I work on have had to switch to git. 
> Younger developers coming into the organisation know git but have 
> invariably never heard of mtn. Also git does allow for history 
> rewriting, which I know is a thorny issue to some, but the reality is 
> that it is needed and very useful (e.g. someone accidentally checks in 
> some creds etc). Whilst you could do this in mtn it was much more 
> painful. History is littered with examples of better technology losing 
> out over more inferior (remember the video-2000/betamx/vhs debate?).

monotone also keeps tracks of moves, renames, etc, and merges on the
appropriate file. Where as git guesses.

But perhaps the biggest differences aren't technical but cultural.

Somebody previously mentioned git requires rebase. I think some projects
really overuse git rebase which can give it a really bad name - e.g. a
previous project of mine required rebasing a chosen set of patches for
every test deploy. Urgghh.

Git doesn't actually require rebase anymore then monotone requires it.
But nobody has written an automated "rebase" tool for monotone. It has
to be done manually. Plus I suspect you may not be able to reuse the
same branch name except maybe in strict set of circumstances (e.g. never
pushed to a remote repo, on local repo only, etc).

With monotone the culture is to save/preserve everything. Just spent the
last several weeks doing a rewrite only to find it was completely flawed
and unusable? Keep it. Spent several weeks writing a change and your
branch got merged? Keep it. Made an experimental change, rewrote parts
of it numerous times before it was mergable? Keep it. etc.

Where as the culture in git is to delete everything that is not
important to the project anymore. That dead end branch no longer is
important anymore. Delete it. You might be able to save it somewhere
else but not the official repo. That merged branch isn't important
anymore. Delete it. Those experimental bits?? Nobody cares about them
anymore, create a new branch (or rebase) with just the important changes
that are required for the project. Another words: delete it.

Is use to belong in the first camp. but more and more been moving to the
later camp. Sure that dead end branch could be resurrected. But chances
are by that stage I probably would rewrite it anyway. And nobody wants
to see 20+ commits in the commit history of me trying to update a
comment on a single line to meet the overly strict standards of code
review at that organisation (e.g. all comments must start with a capital
letter and end in a full stop). This is just noise and adds 0 value to
the project. Nor does it really matter that commit XYZ was part of
branch "fix_bokren_ZZZ" or that the branch name had a spelling mistake.
Or didn't meet naming conventions for the project.

But I understand that some people really like being able to go back in
history and understand which branch is which. Or be able to review dead
ends, stuff that often gets deleted under git. I guess this is where the
monotone approach really is better.

As much as I like git, I am a bit disappointed that git has become the
standard that everyone uses. Because git has been some arbitrary
decisions and trade offs that make sense if you understand its origins
in Linux kernel development space, but these may not necessarily be the
best decisions for all projects. Nor is git really friendly for new
developers, and this adds an extra unwanted barrier to project
participation.

But not using git could also be considered a barrier to project
participation also, particularly with experienced developers.

It would be interesting to know what monotone would look like today if
it was as popular as git is today. For one thing I imagine it would have
more commands developed - like it or not - to meet the requirements of
the "delete it" culture. Such as rebase or something like rebase, for
example.

On another note, git is known to perform badly when you have a repo with
a single file that is slowly and constantly growing and has a huge
history. e.g. https://lwn.net/Articles/774635/ - just wondering can
monotone handle this extreme case any better?
-- 
Brian May <brian@microcomaustralia.com.au>