A proposed Subversion vision and roadmap
A proposed Subversion vision and roadmap
Posted Apr 5, 2010 8:07 UTC (Mon) by sitaram (guest, #5959)Parent article: A proposed Subversion vision and roadmap
As for stuff like this: "They need centralization. They need control. They need meaningful path-based authorization. They need simplicity.", all I can say is that the implication that you cannot get control, centralisation, and simplicity in a DVCS, is at least 75% bovine excreta.
Path-based auth is interesting. I realise there are cases (like gaming, as some comments said) where git (etc) may be a bad choice due to huge binaries and the need to do full clones.
But I also think that in a typical corporate environment (which they now claim to be their main target market) this is far more likely to be management failure and a "that's the way we've always done it" attitude than any *real* need.
I am the author of a project called gitolite that does an excellent job of branch-level access control for multiple git repositories on a central server. My target "market" is precisely corporate users of git. So far, I have not seen a situation where **read-access** needs to be restricted to portions of a repo (git can't do that anyway). Write-access does often need to be restricted, and gitolite can let you restrict both by branch name (e.g. only the QA lead can push a commit series into the "QA-done" branch) or by filename (e.g., only the team lead can make changes to the Makefile and files in src/very-important-and-critical-module).
While I may not completely agree with Linus' comment on SVN ("most pointless project ever started", or words to that effect), because it at least taught people what doesn't work, I think continuing on a project that started out as CVS done right is no longer an optimal use of anyone's talent or time.
Posted Apr 5, 2010 22:07 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
A good reason to use SVN is (was?) maturity. Not sure about now but a few years ago there was already a number of great SVN GUIs while the git CLI was still evolving.
Once SVN is here and does the job, depending on the "real needs" there can be very little reason for a costly migration. Migration cost is not just about finding a silver "svn2git" bullet, it's also about re-writing build scripts, training users, etc.
Posted Apr 6, 2010 9:07 UTC (Tue)
by sitaram (guest, #5959)
[Link]
However, that is a far cry from statements like "In short, they desperately need Subversion" :-)
Posted Apr 6, 2010 19:54 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link]
For the individual developer,
Just wait; once the SVN lovers die out, you can just anoint a random clone into central repository rôle ;-)
A proposed Subversion vision and roadmap
A proposed Subversion vision and roadmap
A proposed Subversion vision and roadmap
git svn
is a godsend: No need for a coup d'etat on the SVN server, but get git's local advantages.