Can we skip the discussion about changing VCS ? It's related but really tangent to the actual thread.
Gist on how to setup the remotes to also fetch PRs: https://gist.github.com/piscisaureus/3342247 On Tue, 1 Mar 2016 at 07:21 Michael Raskin <[email protected]> wrote: > Re: automated LibreOffice UI tests: this promises to be complicated. > > >>I rank reasonableness of notions used in UI as > >> monotone > mercurial > SVN > git > >> > >> I am currently undecided about fossil, although it is definitely in the > >> left half of the chain. > >> > > > >I guess, I'll have to take a closer look at fossil and monotone. What do > >you think of darcs? > > I won't recommend any new people to start using monotone now, as there > are some quirks left and the development is almost dead. Playing with it > for an hour and skimming its documentation could be good just to compare > the different approaches. > > I don't know any actively developed DVCS where it is normal to have > multiple projects in a single repository (monotone branch naming > recommendations encourage that) and this makes me sad. > > I don't like some things about fossil, but it does some other things > right, and it is very alive, so you should probably take at look at it > before monotone. > > I admire some of the darcs work, but I have found that its notion do not > fit very well how I think of things. I dunno, maybe pijul will do > a similar thing better. > > A small note: way back when I was evaluating DVCSes (pre-fossil), I have > found design documents that I enjoyed to read for two of them. Darcs and > Monotone. > > >I used mercurial for a little while between SVN and git, back when it was > >written in python, crashy and slow (probably still is, haha), I think I > > Crashy: I doubt it. There were some stupid mistakes back in the old days > that they actually fixed. Not only with stability. > > Slow: I think they got somewhat better. > > Also, for NixPkgs git is slow for me, too: it all boils down to running > stat on all the files, and VCS is less relevant by that time. For small > projects I just don't care about speed, but I do care about keeping some > parts of my sanity. > > (Choosing to spend resources and performance instead of sanity points > also lef me to use Nix) > > >actually managed to destroy data with it. > > Wow. With mercurial it is harder than with git (I used mercurial in > non-trivial situations more than git, but only managed to do any damage > with git). > > With fossil and monotone you more or less have to explicitly say «and > I also want to destroy my data» to destroy any committed data. > > Uncommitted data is more fragile in every system, that's true. > > >SVN is just: you know, why would I need a server to do version control? > > I think there was SVK for that. Also, I meant the mental models and not > implementation details like needing SVK to get distributed control. > > >git to me is just like nixos: I might not appreciate all the curly braces > >and semicolons in particular, but the whole thing being arranged around an > >immutable core + being super fast + having a large, active community is > >just too good to be ignored. > > Immutable core: you mean that the repository format doesn't change or > that it is built around immutable commit DAG? > > I don't really value the first (compared to other things). > > The second is a given anyway. > > Super fast is interesting to me only all else being equal. > > Nix has core design notions that I like. Git is explicitly «get things > done fast» — I will never claim it has bad design, it refuses to have > any. > > Ative community with no core design is not that useful to me… > > >git commands are built around gotchas, so I will not even try to get > >> a better frontend, I will just script whatever workflow is considered > >> acceptable and use the same two scripts to minimize errors. > >> > >Do try magit though. People that like to show of their git frontends, get > >jealous, when I show it to them. And rightfully so. > >Disclaimer: I do find git's concepts quite acceptable and the gotchas to > be > >manageable, I do think that there would be potential in a tool doing > >management of patchsets, like apparently darcs or quilt do. > > OK, thanks for the advice. > > Note that I _love_ monotone (so there is a set of notions around commit > DAG that I find good — it is just Git slang that calls the same thing > different things and different things the same name; also, I like having > monotone automate). > > Some of the things I like to have just in case are probably impossible > to do well on top of Git's syncing model, I think. > > But maybe language consistency is better in magit. Will try, thanks > again. > > > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
