Comments on: Response to "Subversion’s Future?" http://blog.emptyway.com/2008/05/01/response-to-subversions-future/ Programming, Web and all things Computer. Mon, 08 Mar 2010 10:32:22 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Around the web - May 4, 2008 : business|bytes|genes|molecules http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7326 Around the web - May 4, 2008 : business|bytes|genes|molecules Mon, 05 May 2008 04:28:26 +0000 http://blog.emptyway.com/?p=38#comment-7326 [...] them, but the financial model is definitely interesting. WIkiPatents Interview with Paul Graham Subversion & Git Stagerat - a site for live music fans Data stores and [...] [...] them, but the financial model is definitely interesting. WIkiPatents Interview with Paul Graham Subversion & Git Stagerat – a site for live music fans Data stores and [...]

]]> By: Vladimir Sizikov http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7272 Vladimir Sizikov Sat, 03 May 2008 09:43:49 +0000 http://blog.emptyway.com/?p=38#comment-7272 Nihil Est :) The easy branching is just one of the benefits of DVCS, and even if Svn would get the excellent branching (I doubt it though from what I see in the upcoming SVN release), it is still painful to work with repository overseas. It is painful to have a single point of contact, it is painful to put all branches of all people and groups into single repository, and it is slower. And, if the main repo is down that would mean the entire organization is stuck not able to do the work. The main repository would be HUGE, hard to maintain/backup, folks would be stepping on each other toes and blocked the commit until the previous one is finished, etc. Nihil Est :)

The easy branching is just one of the benefits of DVCS, and even if Svn would get the excellent branching (I doubt it though from what I see in the upcoming SVN release), it is still painful to work with repository overseas. It is painful to have a single point of contact, it is painful to put all branches of all people and groups into single repository, and it is slower. And, if the main repo is down that would mean the entire organization is stuck not able to do the work. The main repository would be HUGE, hard to maintain/backup, folks would be stepping on each other toes and blocked the commit until the previous one is finished, etc.

]]> By: Vladimir Sizikov http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7270 Vladimir Sizikov Sat, 03 May 2008 09:39:32 +0000 http://blog.emptyway.com/?p=38#comment-7270 Rich, Oh, one more thing. Mercurial has a first-class windows integration out of box, and that was probably one of the biggest reasons why Solaris/JDK/Mozilla folks selected it over git at the time. Rich,

Oh, one more thing. Mercurial has a first-class windows integration out of box, and that was probably one of the biggest reasons why Solaris/JDK/Mozilla folks selected it over git at the time.

]]> By: Vladimir Sizikov http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7269 Vladimir Sizikov Sat, 03 May 2008 09:37:40 +0000 http://blog.emptyway.com/?p=38#comment-7269 Rich, I use git on Windows with no problems. There are at least two efforts for git on Windows (git in Cygwin and MsysGit). Granted, they don't work as great as on Linux/Unix, they a bit slower, but other than that git does work on Windows just fine. Rich,

I use git on Windows with no problems. There are at least two efforts for git on Windows (git in Cygwin and MsysGit). Granted, they don’t work as great as on Linux/Unix, they a bit slower, but other than that git does work on Windows just fine.

]]> By: Vladimir Sizikov http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7268 Vladimir Sizikov Sat, 03 May 2008 09:35:53 +0000 http://blog.emptyway.com/?p=38#comment-7268 Jonathan Allen, About limiting access. Yes, this one might be in favor of Subversion. But I believe git/hg also have means to solve this, via modules/forest type of thing. But it most projects I've personally seen, the problem that often arises is not about very strict control but about things like mutable tags (in Subversion) when people accidentally change the content of tagged branch and nothing stops them (in default setting). Yes, there *are* tools to adjust the access rights, etc, and they are cumbersome and not very reliable (one error in config file and entire system might be totally open again). Jonathan Allen,

About limiting access. Yes, this one might be in favor of Subversion. But I believe git/hg also have means to solve this, via modules/forest type of thing.

But it most projects I’ve personally seen, the problem that often arises is not about very strict control but about things like mutable tags (in Subversion) when people accidentally change the content of tagged branch and nothing stops them (in default setting). Yes, there *are* tools to adjust the access rights, etc, and they are cumbersome and not very reliable (one error in config file and entire system might be totally open again).

]]> By: sdw http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7258 sdw Sat, 03 May 2008 00:36:25 +0000 http://blog.emptyway.com/?p=38#comment-7258 @Rich: http://code.google.com/p/msysgit/ A preview but it works. @Rich: http://code.google.com/p/msysgit/

A preview but it works.

]]> By: Nihil Est http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7255 Nihil Est Fri, 02 May 2008 23:43:15 +0000 http://blog.emptyway.com/?p=38#comment-7255 So, granted that branch management on Subversion could be much better, and granted that I personally prefer to use DVCSes at this point, let me play devil's advocate and say that your hierarchical development strategy can in fact be done in Subversion (or Perforce or any decent centralized VCS). All you have to do is have each group work in their own branch, and integrate up the repository hierarchy by integrating into different branches. DVCSes make this easier but not because they are distributed, rather because they handle branches and merges properly. I still prefer to use them. But I don't see any clear reason why you can't do them on a CVCS that doesn't make merges more difficult than they need to be. Even SVN can do it, though until/unless they start actually tracking branch/merge points it will be much more hassle than it needs to be. So, granted that branch management on Subversion could be much better, and granted that I personally prefer to use DVCSes at this point, let me play devil’s advocate and say that your hierarchical development strategy can in fact be done in Subversion (or Perforce or any decent centralized VCS). All you have to do is have each group work in their own branch, and integrate up the repository hierarchy by integrating into different branches.

DVCSes make this easier but not because they are distributed, rather because they handle branches and merges properly. I still prefer to use them. But I don’t see any clear reason why you can’t do them on a CVCS that doesn’t make merges more difficult than they need to be. Even SVN can do it, though until/unless they start actually tracking branch/merge points it will be much more hassle than it needs to be.

]]> By: Nihil Est http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7254 Nihil Est Fri, 02 May 2008 23:24:14 +0000 http://blog.emptyway.com/?p=38#comment-7254 @Nicholas: Mercurial and Bazaar both handle case insensitive path names. @Nicholas:

Mercurial and Bazaar both handle case insensitive path names.

]]> By: Nihil Est http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7252 Nihil Est Fri, 02 May 2008 23:12:40 +0000 http://blog.emptyway.com/?p=38#comment-7252 @Rich: Mercurial: http://www.selenic.com/mercurial Bazaar: http://www.bazaar-vcs.org @Rich:

Mercurial: http://www.selenic.com/mercurial
Bazaar: http://www.bazaar-vcs.org

]]> By: Nicholas Ray http://blog.emptyway.com/2008/05/01/response-to-subversions-future/comment-page-1/#comment-7251 Nicholas Ray Fri, 02 May 2008 22:58:36 +0000 http://blog.emptyway.com/?p=38#comment-7251 I enjoy Monotone, but I understand that most would prefer Mercurial. A problem that probally(just a guess) exists with all of them though is that the repositories store the information with case sensitive path names, and thus on window's it is easy to get a folder into the repository with a case differing from the one on disk. I enjoy Monotone, but I understand that most would prefer Mercurial. A problem that probally(just a guess) exists with all of them though is that the repositories store the information with case sensitive path names, and thus on window’s it is easy to get a folder into the repository with a case differing from the one on disk.

]]>