11 ms·

Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get bac

by iand675 12y ago

Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). Let's not forget people that have to travel a lot for work– SVN + airplanes is a match made in hell. Anyone else ever had someone delete or close an open source project that you cared about? Finding a copy with the history that mattered to you could be tricky. Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily. Other objections to this article: * Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this) * The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don't know what the status is for committing to them these days, but there's nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal. I could go on, but the article seems to be griping about UX issues. Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually.

masklinn 12y ago
> The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. And for a third, it opens options which are not available without that. Annotating or bisecting with server round-trips every time is not really an option.
- CHY872 12y ago
  I disagree - I've done bisects on very large codebases, and they take a while (5-10 seconds for a checkout, perhaps). This is all immaterial compared to the time to recompile the code (possibly a minute or two to get everything recompiled (a Java project)).
  - jsight 12y ago
    I have worked on plenty of projects where both of those would have taken much longer than that with a non-DVCS.
Xylakant 12y ago
> Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage". > The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Not in portable computers. I can get a TB, but that's it. I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them. > Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily. That's a strawman. The article does not argue that there's no use-case that's solved by git or and DVCS. It's just that not every use-case is solved by git. I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved. > Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually. I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.
- angersock 12y ago
  Why are you putting build artifacts into source control?
  - Xylakant 12y ago
    Because they're intermediary steps of a process, regenerating them takes an hour and I don't feel like setting up everybody's environment to build them. Most people don't need the capability, but they need the result. Why are you asking?
    - tedunangst 12y ago
      People get pretty religious about what should (or not) be checked in to version control.
pron 12y ago
A semi-distributed DVCS[1], which is what the author actually advocates, allows for local commits and work with no connectivity. [1]: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
tieTYT 12y ago
> Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this) Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead. I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo.
- mahyarm 12y ago
  You could of added a few steps, like find out what is the right svn branch to commit source code to, because they might only accept patches to the dev branch vs the trunk branch for example.
- tankenmate 12y ago
  git has tools to accept email patches, it's just most people don't use it. I'd accept email patches as long as they merge in a sane fashion.
- perlgeek 12y ago
  > Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead. That's more a social issue. How many projects accept patches that go against their submission guidelines? Or coding style guidelines? > I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo. I found that particularly weak. Let's look through them in more detail. 1. Get a copy of the source code 2. Make your change 3. Generate a patch with diff 4. Email it to the mailing list 5. Watch it get ignored Wrong. You can't generate a diff, unless you first made copy of the original sources, or re-download/unpack it. So there's an essential step missing. And often enough, you simply don't have access to the svn repo to do step 1. 1. Fork the repository on GitHub 2. Clone your fork of the source code 3. Make sure you’re on the right branch that upstream expects your patch to be based on, because they totally won’t take patches on master if they expect them on dev or vice-versa. 4. Make a new local branch for your patch 5. Go ahead and make the patch 6. Do a commit 7. Push to a new branch on your GitHub fork 8. Go to the GitHub UI and create a pull request 9. Watch it get ignored 1. is github specific. Gitlab and Bitbucket don't require that 3. applies to SVN projects too. 4. is optional (though highly recommended) But it gets really interesting when you want to do a second, separate patch. Do that svn when you can't commit directly? well, either throw away your first set of changes, or make a complete copy of your whole checkout.
Justsignedup 12y ago
Remember the days when working from home using Clearcase meant 3-minute right clicks? Peprage farms remembers. Sorry shelshock.
wallyhs 12y ago
From the conclusion at the end of the article: "We aren’t going to abandon DVCSes. And honestly, at the end of the day, I don’t know if I want you to. I am, after all, still a DVCS apologist, and I still want to use DVCSes, because I happen to like them a ton. But I do think it’s time all of us apologists take a step back, put down the crazy juice, and admit, if only for a moment, that we have made things horrendously more complicated to achieve ends that could have been met in many other ways." In the next paragraph, the author links to a post that explains how Facebook will soon experience productivity bottlenecks because of their repository size. That post also explains why they don't want to split up their repository and that, "..the idea that the scaling constraints of our source control system should dictate our code structure just doesn't sit well with us." These are not UX gripes and the problems aren't solved by adding more cheap storage.
gcb0 12y ago
> UX issues this is exactly what the author is saying. and he covers your post there much more concisely. all use cases you mentioned are used infinitely less used than the time you want things git make more cumbersome. that's the while point and i think you made your reply after reading only the title of the article. but the trolling succeed. everyone replied. sigh. even me.

by iand675 12y ago

masklinn 12y ago

> The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. And for a third, it opens options which are not available without that. Annotating or bisecting with server round-trips every time is not really an option.

CHY872 12y ago
I disagree - I've done bisects on very large codebases, and they take a while (5-10 seconds for a checkout, perhaps). This is all immaterial compared to the time to recompile the code (possibly a minute or two to get everything recompiled (a Java project)).
- jsight 12y ago
  I have worked on plenty of projects where both of those would have taken much longer than that with a non-DVCS.

Xylakant 12y ago

> Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage". > The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Not in portable computers. I can get a TB, but that's it. I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them. > Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily. That's a strawman. The article does not argue that there's no use-case that's solved by git or and DVCS. It's just that not every use-case is solved by git. I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved. > Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually. I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.

angersock 12y ago
Why are you putting build artifacts into source control?
- Xylakant 12y ago
  Because they're intermediary steps of a process, regenerating them takes an hour and I don't feel like setting up everybody's environment to build them. Most people don't need the capability, but they need the result. Why are you asking?
  - tedunangst 12y ago
    People get pretty religious about what should (or not) be checked in to version control.

pron 12y ago

A semi-distributed DVCS[1], which is what the author actually advocates, allows for local commits and work with no connectivity. [1]: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

tieTYT 12y ago

> Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this) Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead. I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo.

mahyarm 12y ago
You could of added a few steps, like find out what is the right svn branch to commit source code to, because they might only accept patches to the dev branch vs the trunk branch for example.
tankenmate 12y ago
git has tools to accept email patches, it's just most people don't use it. I'd accept email patches as long as they merge in a sane fashion.
perlgeek 12y ago
> Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead. That's more a social issue. How many projects accept patches that go against their submission guidelines? Or coding style guidelines? > I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo. I found that particularly weak. Let's look through them in more detail. 1. Get a copy of the source code 2. Make your change 3. Generate a patch with diff 4. Email it to the mailing list 5. Watch it get ignored Wrong. You can't generate a diff, unless you first made copy of the original sources, or re-download/unpack it. So there's an essential step missing. And often enough, you simply don't have access to the svn repo to do step 1. 1. Fork the repository on GitHub 2. Clone your fork of the source code 3. Make sure you’re on the right branch that upstream expects your patch to be based on, because they totally won’t take patches on master if they expect them on dev or vice-versa. 4. Make a new local branch for your patch 5. Go ahead and make the patch 6. Do a commit 7. Push to a new branch on your GitHub fork 8. Go to the GitHub UI and create a pull request 9. Watch it get ignored 1. is github specific. Gitlab and Bitbucket don't require that 3. applies to SVN projects too. 4. is optional (though highly recommended) But it gets really interesting when you want to do a second, separate patch. Do that svn when you can't commit directly? well, either throw away your first set of changes, or make a complete copy of your whole checkout.

Justsignedup 12y ago

Remember the days when working from home using Clearcase meant 3-minute right clicks? Peprage farms remembers. Sorry shelshock.

wallyhs 12y ago

From the conclusion at the end of the article: "We aren’t going to abandon DVCSes. And honestly, at the end of the day, I don’t know if I want you to. I am, after all, still a DVCS apologist, and I still want to use DVCSes, because I happen to like them a ton. But I do think it’s time all of us apologists take a step back, put down the crazy juice, and admit, if only for a moment, that we have made things horrendously more complicated to achieve ends that could have been met in many other ways." In the next paragraph, the author links to a post that explains how Facebook will soon experience productivity bottlenecks because of their repository size. That post also explains why they don't want to split up their repository and that, "..the idea that the scaling constraints of our source control system should dictate our code structure just doesn't sit well with us." These are not UX gripes and the problems aren't solved by adding more cheap storage.

gcb0 12y ago

> UX issues this is exactly what the author is saying. and he covers your post there much more concisely. all use cases you mentioned are used infinitely less used than the time you want things git make more cumbersome. that's the while point and i think you made your reply after reading only the title of the article. but the trolling succeed. everyone replied. sigh. even me.