[Nix-dev] Re: OpenSSL dowgrade summary

[Marc Weber]

Hi Peter,

> Personally, I like Git a lot, so I'd be all for switching. However, I
> don't see how using Git instead of SVN would have had an impact on that
> particular situation. The version control system doesn't prevent
> breakage -- *testing* does.

Let's have a closer look at my "uncarefulness" and the new issue:
comitting openssl-1.0.0 update and partially reverting it.

Both have in common that the comitter didn't forsee the impacts.
In my case it may have been stupidity - too much stress - uncarefulness
as you've said.
In the openssl issue the reason is: There was good
reason to take action (security update). It's impossible to rebuild
everything before doing such a commit

Both have in common that nobody is interested in this kind of history:

- A commit
- revert A
- ...
- B commit
- revert B

on a branch everybody is using.

In both cases: SVN and GIT you can commit to different branches first
and ask others to review it. In both cases you can merge or cherry-pick
changes into a "main" or "stable" branch. GIT is much more convenient.
You can preview your changes before pushing etc.

How often did this take place in the Nix community:
- start a branch -> improve it -> push upstream.

how often would this have helped?

My current NixOS commit adding two new option was a result of this
workflow. I asked about whether I may commit it. Ludovic Courtès asked
me to add the option and enhance the documentation by using docbook
style.

If we used git I would have pushed a new branch. I would have posted a
diff and maybe a hash. Ludovic Courtès could have pushed enhancements..

At the end we could have "squashed" the branch and comitted one commit
"by Ludovic Courtès and Marc Weber".

Well, this still is no problem: I could start a git svn clone.
I could push it to github or gitoriuous...
We could do collaborative editing on a branch. After reaching consensus
how to commit? Each person who did one commit on the collaborative
branch has to commit his commit. I could commit them. But they would be
labeled "Marc Weber" only becauses I would be comitting using my SVN
account.

That's the main reason why I think that both systems don't play that
well together. SVN itself is fine. But I don't see a way to feed commits
from git into SVN preserving authors and such.
And that's what I'd like to see: Do some development on a "dev" branch.
Talk about it. Tidy it up. Then feed upstream into "stable".

Can this be done efficiently using SVN: tidy branches or commit history
up before feeding upstream?

I also did some benchmarking:
switching a branch (trunk -> stdenv-updates) takes 0.2 sec here.
using svn it takes 3.

Fetching nixpkgs takes as long as fetching nixpkgs using git (including
all of my personal branches and all history!)

If there is a question whom to ask?

svn blame will tell you. git blame as well. Timings (on
all-packages.nix:)

svn: total 46s (rerunning it: 34sec)
git: 6.6s

That's why I prefer git. Because tasks I do  everyday are much faster
for me.

Marc Weber