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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
