[Nix-dev] Commit access

[zimbatm]

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 <7c6f434c at mail.ru> 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
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160301/4a3d38bc/attachment.html