3 ms·

This is a bit of a diversion from Fitzpatrick and Collins-Sussman's talk, but I run into this belief a lot, and want to make a point. I see little evidence her

by gchpaco 17y ago

This is a bit of a diversion from Fitzpatrick and Collins-Sussman's talk, but I run into this belief a lot, and want to make a point. I see little evidence here that Collins-Sussman has finally understood DVCS as a social entity, although he certainly seems to have the technical details down. The strongest argument for DVCS--any DVCS--that I have found is the periodic fights over "committer access" or project direction generally for projects like NetBSD, XEmacs, gcc/EGCS, or glibc/eglibc disappear. I've seen more times than I can conveniently remember a perception of a cabal of committers who communicate exclusively with each other. This looks a lot like the structure of some sort of conspiracy, even though that is rarely the purpose. Even when it is, it's usually trying to work around some productive but extremely difficult person like Ulrich Drepper or Theo de Raadt. DVCSes have the critically important property that there is no longer any inherent technical center of development but that the social center of development is retained (usually). So while there is a technical hierarchy of git repositories that goes to Linus, if you think he's an idiot and want to take it a different direction, it's easy to do that--and if he decides you have a good idea in the end, he can merge with you without huge amounts of effort. Collins-Sussman has been concerned, publically, that there's some splintering process that DVCSes enable and that SVN prevents. But this perception is one you can only arrive at if you are in control of the SVN repository--if you are trying to submit patches to somebody doing this, and you don't have write access on the SVN server for branches or whatever (which imposes a nontrivial amount of effort), you more or less have to do this splintering on your own, without any tool support. In my experience DVCSes don't make this any more common than it was once; it's just that now these private splinters are visible, and can be integrated. Another secondary thing that's very convenient for me is that I can make many small changes and push them all at once when I'm happy with them--because they're small they're easier to review. But this is a workflow issue, it's not that one couldn't do this with SVN.

delano 17y ago
DVCSes have the critically important property that there is no longer any inherent technical center of development but that the social center of development is retained (usually). This is a really good point. It allows the social structure of the project to grow and change in a very natural way which makes it not only easier to adapt as committers come and go, but effortless.
- stcredzero 17y ago
  The social center is also decided by a kind of marketplace. With central control of a repository, you can have what amounts to an "irrigation rights empire" -- a totalitarian regime (perhaps with some democratic window dressing) based on one party's control over some sort of infrastructure.
durin42 17y ago
Another secondary thing that's very convenient for me is that I can make many small changes and push them all at once when I'm happy with them--because they're small they're easier to review. But this is a workflow issue, it's not that one couldn't do this with SVN. This is part of the problem with DVCSes - you do your work off in a cave, and then when it's "perfect" you submit it for inclusion. Note that SVN doesn't lack this problem - it can even make it worse. It's just far more common in my experience for people to do work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk than with SVN, because it's so easy to maintain that fork off in neverland. After all, just look at the comments (on this article no less!) about how "once I clean X up, I'll put it on {github,bitbucket,google code}." That's the kind of attitude that means it'll almost never (statistically) be seen by anyone other than the original author (which is likely true anyway, only one of my projects has ever really attracted anything resembling attention). Note that Ben isn't convinced that this risk of DVCSes outweighs their (admittedly large) benefits. It merely aggravates a very serious problem to a point where it becomes a complete nightmare.
- gchpaco 17y ago
  My experience has been that the alternative to many small commits, occasionally batched (because who really wants to look at "cleaned up Checkstyle's warnings" endlessly?) is one big commit two or three times a day, which is significantly harder to digest. But in any case, as you allude to in your response, this is a social problem. I contend that the sort of people who work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk would either do that anyway (see Linux kernel features before they make it into the mainland trunk for evidence; this was going on well before git, and if anything git has made it less of a problem) or wouldn't contribute at all.

by gchpaco 17y ago

delano 17y ago

DVCSes have the critically important property that there is no longer any inherent technical center of development but that the social center of development is retained (usually). This is a really good point. It allows the social structure of the project to grow and change in a very natural way which makes it not only easier to adapt as committers come and go, but effortless.

stcredzero 17y ago
The social center is also decided by a kind of marketplace. With central control of a repository, you can have what amounts to an "irrigation rights empire" -- a totalitarian regime (perhaps with some democratic window dressing) based on one party's control over some sort of infrastructure.

durin42 17y ago

Another secondary thing that's very convenient for me is that I can make many small changes and push them all at once when I'm happy with them--because they're small they're easier to review. But this is a workflow issue, it's not that one couldn't do this with SVN. This is part of the problem with DVCSes - you do your work off in a cave, and then when it's "perfect" you submit it for inclusion. Note that SVN doesn't lack this problem - it can even make it worse. It's just far more common in my experience for people to do work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk than with SVN, because it's so easy to maintain that fork off in neverland. After all, just look at the comments (on this article no less!) about how "once I clean X up, I'll put it on {github,bitbucket,google code}." That's the kind of attitude that means it'll almost never (statistically) be seen by anyone other than the original author (which is likely true anyway, only one of my projects has ever really attracted anything resembling attention). Note that Ben isn't convinced that this risk of DVCSes outweighs their (admittedly large) benefits. It merely aggravates a very serious problem to a point where it becomes a complete nightmare.

gchpaco 17y ago
My experience has been that the alternative to many small commits, occasionally batched (because who really wants to look at "cleaned up Checkstyle's warnings" endlessly?) is one big commit two or three times a day, which is significantly harder to digest. But in any case, as you allude to in your response, this is a social problem. I contend that the sort of people who work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk would either do that anyway (see Linux kernel features before they make it into the mainland trunk for evidence; this was going on well before git, and if anything git has made it less of a problem) or wouldn't contribute at all.