4 ms·
Here's the thing though. I have been using SVN for years and am not learning Git. For a long time I figured I was just disoriented and eventually it would com
by einhverfr 14y ago
Here's the thing though. I have been using SVN for years and am not learning Git. For a long time I figured I was just disoriented and eventually it would come. Now I am less convinced. The article really described my experience pretty well to the point where I am thinking the only sane way to use git is along with subversion.....
In essence, the more I learn, the less I like it, and the more convinced I am that it isn't what I need right now. Building accounting software there are certain things I need in a revision control system. These are:
1) revision control as audit trail. I need to know who committed a change and I need an audit trail on that. SVN isn't perfect here. I'd like to be able to audit changes to commit logs too, but that's pretty minor stuff.
2) collaboration among a smallish number of committers (right now maybe 4 active at any given point in time).
Folks have pushed git because it makes it easier for users to share modifications with eachother. That's fine, and it's a good point, but it isn't worth getting rid of a clear and reliable audit trail in order to achieve. To this end I suspect we are more likely to pursue a hybrid solution with all the complexity that provides (and indeed it is already partly implemented) than a pure git solution.
Allowing rewrite of commits is a problem not because developers might do it but rather because you can't show that developers didn't do it. If there is a question about whether a security issue was intentionally added to the code or not you need to have a clear audit trail. A basic principle of any audit trail is that your audit trails may not be overwritten.
- mdwrigh2 14y agoJust require commits that are signed off with GPG keys. Then you have a clean, verifiable audit trail through git. Beyond that, you'll have the full development history on your machine, which they can't just arbitrarily change.
- einhverfr 14y agoDo you think that's more or less complex than just using svn-git to manage the authoritative audit-trail repository?
- mdwrigh2 14y agoLess, managing two version control systems seems like insanity (speaking as one who's had to do it in the past). Having people sign their commits is dead simple in Git, and you could setup hooks to make sure every commit is signed before you accept it. An alternative (or additional) solution is to setup a server like Shawn suggests in this e-mail: http://git.661346.n2.nabble.com/Implementing-commit-signing-tp1312464p1312616.html http://git.661346.n2.nabble.com/Implementing-commit-signing-...
- rmc 14y agoGit version numbers are actually SHA1 hashes that are based on all the files and the entire history of the project up to there. If you modify the history in any way, then that will be a new version number and you know something has changed. You can optionally GPG sign a commit/tag which, again, will be invalid if any part of the history is changed.
- lrem 14y agoThis actually is the usage scenario for which Fossil[1] was created (in fact DRH made it to be in accordance to some aviation industry norms, don't remember details). Furthermore, one of the ideas behind Fossil's design was to minimize the learning curve for someone who already knows SVN. Disclosure: I occasionally committed something to Fossil. [1]: http://fossil-scm.org/ http://fossil-scm.org/
- einhverfr 14y agoFossil looks promising. Thanks. I have bookmarked it. Of course there was a typo in my previous post. I am "now" learning git, not "not" learning git.