On 3/20/2012 10:56 PM, Joel de Guzman wrote:
On 3/21/2012 8:41 AM, Edward Diener wrote:
On 3/20/2012 7:03 AM, Julian Gonggrijp wrote: ... snip
Well, allow me to present some fair reasoning to you.
With regard to git versus svn: I think enough fair reasons have been given why git (or a DVCS in general) is better than svn. I'm not going to repeat those arguments here.
I have never heard a single technical argument, in all the endless mentions of Git among the people riding that bandwagon, why Git is better than SVN, or even why any DVCS is better than a centralized SCCS. I consider this whole move to Git and/or DVCS among "hip" programmers little more than a move to conform with what others are doing and feel "cool".
I am perfectly willing to read well-chosen technical arguments but not from people already sold on one side or the other. But I really despair of anyone being able to present such arguments in the atmosphere created by Git fanatics and DVCS fanatics. The only thing I have gotten from all this is "I've tried it, I like it, and therefore its superior".
Feel free, anyone, to point me to a purely technical discussion, article, whatnot, explaining the practical reasons why using a DVCS, or Git, is more productive and more pleasurable than using a centralized SCCS like Subversion.
I'm not a Git, or DVCS fanatic. I'll just use whatever tool required to get the job done. I'm OK with SVN. It works. If you read my previous comments on this topic (from last year when this was heavily discussed), you'll see that I question the Git move. To me, and I mentioned this before: "A Good Craftsman Never Blames His Tools". I know a very good luthier who craft world-class guitars using only a pocket knife. And I take that to heart with crafting code as well. I find it funny when people blame SVN, the C++ compiler, etc, etc, for inadequacies in order to flaunt these new shiny tools (Git, Java in the 90s or name-your-new- compiler-here).
That is to say, I am not among the "hip". I tend to use the simplest of tools: the most basic text editor and a decent compiler, at the very least.
Having presented my neutrality, let me present a case *FOR* DVCS...
From the beginning, Spirit had it's own community, mildly detached from Boost. Spirit contributors come and go. We once develop code using SourceForge (using CVS, then SVN). I give contributors write access as needed. Once, stable, I move or merge the code to Boost. It so happens that we had a more frequent release cycle than Boost (at the time). Each move was soo frustratingly difficult and time consuming (not to mention that I lose and never bothered about the commit histories when moving code to Boost from SF; it just was not worth the hassle. After all, SF was the master with all the histories and the one in Boost was just a copy).
That was fine, but there was something in Boost that we need: regular testing by multiple people on different platforms and compilers. At one point, because of that need, we stopped using SF and finally moved to Boost for development. One drawback that I sorely miss from being independent from Boost is the right to give write access. Now, whenever a new contributor comes along, I have to ask permission from the Boost-Owners for write access to the Boost repo. And, a write access privs gives everyone access to the whole boost repo, instead of being limited to Spirit only. Also, I often wondered about past Spirit-devs who are inactive now. They still have write access, but I just let them be. Not being in control is a major disadvantage for me. It's my library and I want to have more control.
What I want is to have a system where I can decouple Spirit from the Boost central repository again. I want to regain the right to give Spirit developers write access to this decoupled repository. I want Spirit-devs to develop code, create branches, etc. in this repository. I want to be able to commit upstream into the Boost repo on a regular basis and thus take advantage of Boost testing. I want the commit histories of my upstream merge be intact on all moves and merges.
It is obvious to me now that what Spirit needs is DVCS. I don't care which (Git or Hg). I tried both on my own and I find both satisfactory to my minimal needs.
I can certainly craft something using a pocket knife and a chisel, but I certainly wouldn't mind a dremel power tool :-)
(PS. I tried Git-SVN and hgsubversion without luck. I simply can't get them to work. I'm guessing that these facilities are not well supported. In my experience, they simply bork out when I try to clone the Boost repository)
Thanks ! I respect you as a programmer and the experience you have related. You have given practical advantages to a DVCS in your explanation. But now let me argue the other side. I am pretty sure you can take an SVN repository and give users access to whatever part of it you want while restricting access to the rest. When you do that what is the difference from users having a DVCS to play with and their own branch of an SVN repository to manipulate ? Conceptually in my mind it is the same thing. Yes, I recognize that psychologically the feeling that one has one's own local repository to play with, and then merge with other repositories, is enticing to users. Bu how is this different from: 1) Creating a local SVN repository and importing some branches from another SVN repository. and/or 2) Having one's own branch of an SVN repository as one's own. What I object to about the DVCS people is that they seem to assert that because DVCS has a model they like, where there is no concept of a central repository, that this is automatically superior in some non-practical and perhaps personal way. I do not doubt that DVCS systems may have some very good tools for merging together various local repositories into some other one(s), but what does this freedom really amount to ? The end-user feels better because it feels like one can work separately more easily and then join one's work with others, but in reality a central repository system has the same "tools". Furthermore merging work with others is NEVER as easy as people would like to think it is. I am so tired of hearing about how all this merging of code just automatically works, and works flawlessly. Who are we kidding ? I can understand your feeling of separating Spirit from Boost and then joining back into Boost as you wish, and perhaps indeed a DVCS has better tools to do this than Subversion, but can you really say this is a matter of DVCS's being inherently better than a centralized SCCS in some way to enable this ? How is this process different than merging whole branches or parts of branches back into Subversion. However it is done merging is very hard and careful work and it is impossible for me to believe that a DVCS has something inherently about it that automatically makes it better. I guess I am saying that on a practical basis a DVCS may be more flexible than a centralizes SCCS, but I see no inherent reason for this. Eddie