4 ms·

> Subversion uses a centralized revision control model. Ben Collins-Sussman, one of the designers of Subversion, believes a centralised model would help prevent

by voidr 11y ago

> Subversion uses a centralized revision control model. Ben Collins-Sussman, one of the designers of Subversion, believes a centralised model would help prevent "insecure programmers" from hiding their work from other team members. source: http://en.wikipedia.org/wiki/Apache_Subversion#Limitations_and_problems http://en.wikipedia.org/wiki/Apache_Subversion#Limitations_a... Sounds like you should be using Subversion then. Do you understand how history rewriting works in git? do you understand why it's there? do you understand why people use it? Personal beliefs don't advance computing, hard facts do.

durin42 11y ago
Note that Ben (a personal friend) has been an enthusiastic user of Mercurial for several (4? 5?) years, and is pretty happy with it. He was even using hgsubversion for a while I think. Note that there's a lot of social problems around DVCS, and the thing Ben worried about is still a _real problem_. I get potential contributors showing up with months of work, and it's an enormous pain in the ass (both for them to rewrite and for me to beg them to work with me) when they did something architecturally unacceptable early in the process that a simple 2 minute review could have caught.
- krupan 11y ago
  But would the insecure people have done that work at all if they knew they would be forced to commit it publicly? Maybe so, but would it all be one huge commit to svn instead of maybe a string of more concise commits to git or mercurial? I just envision someone insecure (like I feel at times) saying, well, I'll just clone this and play around on my own machine. Then after making some commits and building up courage, saying, OK, I'll try and go public with this. With centralized VCS that seems less likely to me. The insecure programmer just won't even try. I don't know, it's probably different for different people.
btreecat 11y ago
>Do you understand how history rewriting works in git? do you understand why it's there? do you understand why people use it? I do not. Could you please explain? At work I learned to use mercurial and never felt the need to pick up git since I can use the hg-git plugin.
- krupan 11y ago
  First of all, the history re-writing of both git and mercurial do not throw any history away[1], let's be clear on that. The history re-writing allows you to commit willy-nilly as often as you want, and then allows you to clean up those commits to make them readable, useful, and presentable to your team by combining commits, reordering commits, deleting commits, etc. The freedom to commit (and have an undo-point to go back to) at any time is very liberating and anxiety reducing :-) Using VCS's other than git and mercurial people still end up doing essentially the same thing, they are simply required to do all the cleanup outside of the VCS before they commit. Almost nobody commits every sloppy, intermediate, untested edit of their files to svn or perforce. Users of those VCS's "rewrite" and "throw away" history just the same. Footnote: 1. They both keep the original commits around after they are replaced by "rewritten" or "edited" commits. git does eventually delete the old history with its garbage collection, but it takes a number of weeks for that to happen. Mercurial saves backup bundle files (or obsolete changesets if using the evlove plugin) indefinitely. You have to manually delete them.

by voidr 11y ago

durin42 11y ago

Note that Ben (a personal friend) has been an enthusiastic user of Mercurial for several (4? 5?) years, and is pretty happy with it. He was even using hgsubversion for a while I think. Note that there's a lot of social problems around DVCS, and the thing Ben worried about is still a _real problem_. I get potential contributors showing up with months of work, and it's an enormous pain in the ass (both for them to rewrite and for me to beg them to work with me) when they did something architecturally unacceptable early in the process that a simple 2 minute review could have caught.

krupan 11y ago
But would the insecure people have done that work at all if they knew they would be forced to commit it publicly? Maybe so, but would it all be one huge commit to svn instead of maybe a string of more concise commits to git or mercurial? I just envision someone insecure (like I feel at times) saying, well, I'll just clone this and play around on my own machine. Then after making some commits and building up courage, saying, OK, I'll try and go public with this. With centralized VCS that seems less likely to me. The insecure programmer just won't even try. I don't know, it's probably different for different people.

btreecat 11y ago

>Do you understand how history rewriting works in git? do you understand why it's there? do you understand why people use it? I do not. Could you please explain? At work I learned to use mercurial and never felt the need to pick up git since I can use the hg-git plugin.

krupan 11y ago
First of all, the history re-writing of both git and mercurial do not throw any history away[1], let's be clear on that. The history re-writing allows you to commit willy-nilly as often as you want, and then allows you to clean up those commits to make them readable, useful, and presentable to your team by combining commits, reordering commits, deleting commits, etc. The freedom to commit (and have an undo-point to go back to) at any time is very liberating and anxiety reducing :-) Using VCS's other than git and mercurial people still end up doing essentially the same thing, they are simply required to do all the cleanup outside of the VCS before they commit. Almost nobody commits every sloppy, intermediate, untested edit of their files to svn or perforce. Users of those VCS's "rewrite" and "throw away" history just the same. Footnote: 1. They both keep the original commits around after they are replaced by "rewritten" or "edited" commits. git does eventually delete the old history with its garbage collection, but it takes a number of weeks for that to happen. Mercurial saves backup bundle files (or obsolete changesets if using the evlove plugin) indefinitely. You have to manually delete them.