[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is monotone dead, or is there a path forward?
From: |
CooSoft Support |
Subject: |
Re: Is monotone dead, or is there a path forward? |
Date: |
Sun, 6 Jun 2021 14:18:12 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
In my experience the merging in mtn
presents the developer with far fewer conflicts to resolve. Plus
you can merge multiple branches in one go by `baptising' those dev
branches into the target developer/integration branch. So it
doesn't stand out at first, you just notice after a while that you
have a lot less work than you'd expect with other SCMs.
As for git. Well one of the reasons
that mtn is very good at merging, apart from any algorithm that is
used to do it, is that it relies on the fact that you have a
complete history and that any branch being merged must have
branched off at some point from the branch that it is being merged
back into. Otherwise you have to do a manual merge. Git doesn't
place that `same origin branch' restriction on you.
Others on this mailing list may have a
more in depth answer for you though. These are just my
observations.
On 06/06/2021 13:49, Hugo Cornelis
wrote:
I have used monotone for a few years and was fine with
it.
I used to hear a lot and still hear now and then that the
approach to merging in monotone is / was superior to the
approach taken in git. It is something I have never
understood. My experience with merges in monotone is
actually quite limited (compared to experience with merges
with git).
How do they compare wrt merges? What is so fundamentally
different between them? And why makes this difference such a
profound impact to the developer experience?
Just wondering.
Would it be possible to integrate monotone-like merges into
git?
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
Isn't it just that the term 'history rewriting' was
badly chosen?
Something like 'commit refactoring' would have been
more appropriate.
Rewriting history sounds as being dishonest. Commit
refactoring sounds like moving forward.
Hugo
painful. History is littered with examples of better
technology losing
out over more inferior (remember the video-2000/betamx/vhs
debate?).
Moving forward doesn't necessarily mean making progress.
On 06/06/2021 10:00, Michael Raskin wrote:
>> As people noted in last months / years... the
worlds OS, apps,
>> developers, and tech oriented operating system /
repo / code / porters
>> eyeballs users and interactors have more or less
moved en masse
>> to git, primarily on github, often augmented by
running
>> their own git copies in house if they are a large
project.
> (for the record, I still run projects where I do not
expect too many
> external contributions in Monotone, with a public git
repo explicitly
> marked as «a dump of random snapshots from the real
development
> repositories», which makes me kind of interested in
having a version
> buildable without using library versions dropped
because of open CVEs)
>
>> It's unlikely under what is now an ecosystem
settled
>> into git, that any new talent or otherwise will
bother
>> trying to use monotone or any other repo to fetch
>> patch hack commit etc on anyones code, regardless
>> of whether that code is an OS, a repo, or an app.
>> It's the language problem, if you are one speaking
Z,
>> in a world where everyone else speaks only A,
>> you will need to adapt to them.
>>
>> If monotone wants to survive in a compileable state
>> across OS, to maintain an example presence that
>> alternative repo embodiments are available that do
run
>> and can be studied and tried out, it needs at
minimum...
>>
>> a) A tarball release that compiles against the
latest
>> versions of all external libraries, and on the
latest
>> release of FreeBSD and Linux-Debian.
> Yes, this is clearly a non-negotiable requirement.
>
>> and
>>
>> b) A github repo (and ticket system) that is
considered an
>> "upstream" that can be interacted with and that
will accept
>> maintenance patches from the OS and userspace.
> There is a non-trivial chance of success with _just_ a
working public
> bugtracker and patches mailing list if the development
is about API
> compatibility fixes.
>
>> and
>>
>> c) Some public FYI blurb advert when doing those
interactions,
>> and in the topline of the toplevel README, that
monotone is
>> accepting new maintenance / dev people. No one
lives or
>> maintains forever, thus wise continually seek new
eyballs and
>> people in wherever the new places are.
> Indeed, someone able to make a release whenever APIs
need an update is
> more important than the quality of such release. (It
probably doesn't
> have enough changes to break stuff anyway)
>
>> Otherwise monotone dies.
>>
>> If there are compilation and bug patches out there
waiting to
>> be applied, and tarballs with them needing cut,
then someone
>> or some group throwing a monotone continuance
project up on
>> github and working those things there is probably
not a bad idea.
>>
>
>
>
--
- Re: Is monotone dead, or is there a path forward?, (continued)
- Re: Is monotone dead, or is there a path forward?, grarpamp, 2021/06/06
- Re: Is monotone dead, or is there a path forward?, grarpamp, 2021/06/06
- Re: Is monotone dead, or is there a path forward?, Michael Raskin, 2021/06/06
- Re: Is monotone dead, or is there a path forward?, Brian May, 2021/06/06