[Nix-dev] Commit access

[Michael Raskin]

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.