Re: Is monotone dead, or is there a path forward?
CooSoft Support <[email protected]> Sun, 6 Jun 2021 14:18:12 +0100
| Newsgroups | gmane.comp.version-control.monotone.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------6241966B61D840376B33AF3D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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? > > On Sun, Jun 6, 2021 at 2:32 PM CooSoft Support > <[email protected] <mailto:[email protected]>> wrote: > > 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. > >> > > > > > > > > > > > -- > Hugo > > > > -- > > Hugo Cornelis, Ph.D. > > Agora Classica -- CTO > http://www.agoraclassica.com/ <http://www.agoraclassica.com/> > > GENESIS-3 -- lead architect > http://www.genesis-sim.org/ <http://www.genesis-sim.org/> > --------------6241966B61D840376B33AF3D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">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.</div> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">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.</div> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">Others on this mailing list may have a more in depth answer for you though. These are just my observations.<br> </div> <div class="moz-cite-prefix">On 06/06/2021 13:49, Hugo Cornelis wrote:<br> </div> <blockquote type="cite" cite="mid:CAJrGA0G1bjqnGZh5oD2VcFvbz3AGnaXP0Psw_KEc7WOrH867Cw@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div dir="ltr"> <div><br> </div> <div>I have used monotone for a few years and was fine with it.</div> <div><br> </div> <div>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).<br> </div> </div> <div><br> </div> <div>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?<br> </div> <div><br> </div> <div>Just wondering.</div> <div><br> </div> <div>Would it be possible to integrate monotone-like merges into git?<br> </div> <div><br> </div> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Sun, Jun 6, 2021 at 2:32 PM CooSoft Support <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I loved using Monotone and agree that the merging in mtn is far superior <br> to the run of the mill merging you get with git (after all it's site did <br> refer to it as a stupid/dumb content tracker). In fact mtn's merging is <br> the best I've ever used. I liked the fact that changesets were stored <br> efficiently as compressed deltas in mtn as well. However the world has <br> moved on and the projects that I work on have had to switch to git. <br> Younger developers coming into the organisation know git but have <br> invariably never heard of mtn. Also git does allow for history <br> rewriting, which I know is a thorny issue to some, but the reality is <br> </blockquote> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> that it is needed and very useful (e.g. someone accidentally checks in <br> some creds etc). Whilst you could do this in mtn it was much more <br> </blockquote> <div><br> </div> <div> <div>Isn't it just that the term 'history rewriting' was badly chosen?</div> <div><br> </div> <div>Something like 'commit refactoring' would have been more appropriate.</div> <div><br> </div> <div>Rewriting history sounds as being dishonest. Commit refactoring sounds like moving forward.<br> </div> <div><br> </div> <div>Hugo</div> </div> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> painful. History is littered with examples of better technology losing <br> out over more inferior (remember the video-2000/betamx/vhs debate?).<br> <br> Moving forward doesn't necessarily mean making progress.<br> On 06/06/2021 10:00, Michael Raskin wrote:<br> >> As people noted in last months / years... the worlds OS, apps,<br> >> developers, and tech oriented operating system / repo / code / porters<br> >> eyeballs users and interactors have more or less moved en masse<br> >> to git, primarily on github, often augmented by running<br> >> their own git copies in house if they are a large project.<br> > (for the record, I still run projects where I do not expect too many<br> > external contributions in Monotone, with a public git repo explicitly<br> > marked as «a dump of random snapshots from the real development<br> > repositories», which makes me kind of interested in having a version<br> > buildable without using library versions dropped because of open CVEs)<br> ><br> >> It's unlikely under what is now an ecosystem settled<br> >> into git, that any new talent or otherwise will bother<br> >> trying to use monotone or any other repo to fetch<br> >> patch hack commit etc on anyones code, regardless<br> >> of whether that code is an OS, a repo, or an app.<br> >> It's the language problem, if you are one speaking Z,<br> >> in a world where everyone else speaks only A,<br> >> you will need to adapt to them.<br> >><br> >> If monotone wants to survive in a compileable state<br> >> across OS, to maintain an example presence that<br> >> alternative repo embodiments are available that do run<br> >> and can be studied and tried out, it needs at minimum...<br> >><br> >> a) A tarball release that compiles against the latest<br> >> versions of all external libraries, and on the latest<br> >> release of FreeBSD and Linux-Debian.<br> > Yes, this is clearly a non-negotiable requirement.<br> ><br> >> and<br> >><br> >> b) A github repo (and ticket system) that is considered an<br> >> "upstream" that can be interacted with and that will accept<br> >> maintenance patches from the OS and userspace.<br> > There is a non-trivial chance of success with _just_ a working public<br> > bugtracker and patches mailing list if the development is about API<br> > compatibility fixes.<br> ><br> >> and<br> >><br> >> c) Some public FYI blurb advert when doing those interactions,<br> >> and in the topline of the toplevel README, that monotone is<br> >> accepting new maintenance / dev people. No one lives or<br> >> maintains forever, thus wise continually seek new eyballs and<br> >> people in wherever the new places are.<br> > Indeed, someone able to make a release whenever APIs need an update is<br> > more important than the quality of such release. (It probably doesn't<br> > have enough changes to break stuff anyway)<br> ><br> >> Otherwise monotone dies.<br> >><br> >> If there are compilation and bug patches out there waiting to<br> >> be applied, and tarballs with them needing cut, then someone<br> >> or some group throwing a monotone continuance project up on<br> >> github and working those things there is probably not a bad idea.<br> >><br> ><br> ><br> ><br> <br> <br> </blockquote> </div> <br clear="all"> <br> -- <br> <div dir="ltr" class="gmail_signature"> <div dir="ltr"> <div> <div dir="ltr"> <div> <div dir="ltr"> <div> <div dir="ltr">Hugo<br> <br> <br> <br> --<br> <br> Hugo Cornelis, Ph.D.<br> <br> Agora Classica -- CTO<br> <a href="http://www.agoraclassica.com/" target="_blank" moz-do-not-send="true">http://www.agoraclassica.com/</a><br> <br> GENESIS-3 -- lead architect<br> <a href="http://www.genesis-sim.org/" target="_blank" moz-do-not-send="true">http://www.genesis-sim.org/</a><br> <br> </div> </div> </div> </div> </div> </div> </div> </div> </div> </blockquote> <p><br> </p> </body> </html> --------------6241966B61D840376B33AF3D--