3 ms·

SVN has PHP bindings, git doesn't. No matter what you think of PHP or SVN, it's difficult to argue that there is no single use case which wouldn't be affected b

SVN has PHP bindings, git doesn't. No matter what you think of PHP or SVN, it's difficult to argue that there is no single use case which wouldn't be affected by this (I myself have recently had to choose SVN for a project for this very reason).

phaemon 13y ago
Isn't https://github.com/libgit2/php-git https://github.com/libgit2/php-git what you're looking for?
- Xylakant 13y ago
  you're certainly aware that libgit2 is a reimplementation of git, largely sponsored by github since the original git libraries are binding-unfriendly to say the least. The de-facto ruby "bindings" (grit) were a mere wrapper around cli git and afaik this used to be the only way to go. I tried to use libgit2 for a project last year and a coworker did a couple of patches and I can say that there's still a lot of ground to cover until libgit2 is at least somewhat feature complete. Back then, clone via SSH and other _must_have_ features were unimplemented.
  - phaemon 13y ago
    How unlucky, you must have just missed it. Clone via ssh was added in May last year! What were the other must-haves that were missing?
  - emmelaich 13y ago
    Linus uses libgit2 [0] albeit as a data format, not as a basis for VCS. [0] https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
dasil003 13y ago
And surprise! I did not argue that. I wish people would read my comment a bit more carefully.
- oneeyedpigeon 13y ago
  You said: "If any SVN dev truly believes that svn is better than git in any technical sense then I wouldn't trust the engineering judgment of that developer." and I gave one example in which svn 'is better than git in a technical sense'.
  - dasil003 13y ago
    Poor choice of words on my part, but when I said "in a technical sense", I meant it's data model and architecture. Bindings are just a feature that can be written at any time, data model and architecture are something that can never be fixed. More importantly, I specifically alluded to use cases that svn is better than git for. In no way did I ever "argue that there is no single use case which wouldn't be affected by this".

phaemon 13y ago

Isn't https://github.com/libgit2/php-git https://github.com/libgit2/php-git what you're looking for?

Xylakant 13y ago
you're certainly aware that libgit2 is a reimplementation of git, largely sponsored by github since the original git libraries are binding-unfriendly to say the least. The de-facto ruby "bindings" (grit) were a mere wrapper around cli git and afaik this used to be the only way to go. I tried to use libgit2 for a project last year and a coworker did a couple of patches and I can say that there's still a lot of ground to cover until libgit2 is at least somewhat feature complete. Back then, clone via SSH and other _must_have_ features were unimplemented.
- phaemon 13y ago
  How unlucky, you must have just missed it. Clone via ssh was added in May last year! What were the other must-haves that were missing?
- emmelaich 13y ago
  Linus uses libgit2 [0] albeit as a data format, not as a basis for VCS. [0] https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV

dasil003 13y ago

And surprise! I did not argue that. I wish people would read my comment a bit more carefully.

oneeyedpigeon 13y ago
You said: "If any SVN dev truly believes that svn is better than git in any technical sense then I wouldn't trust the engineering judgment of that developer." and I gave one example in which svn 'is better than git in a technical sense'.
- dasil003 13y ago
  Poor choice of words on my part, but when I said "in a technical sense", I meant it's data model and architecture. Bindings are just a feature that can be written at any time, data model and architecture are something that can never be fixed. More importantly, I specifically alluded to use cases that svn is better than git for. In no way did I ever "argue that there is no single use case which wouldn't be affected by this".