5 ms·

Agree. If your bottleneck is your source control tool, you're doing something wrong.

by axod 17y ago

DougBTX 17y ago
Discussing bottlenecks oversimplifies, it assumes everything goes down one pipeline. Small changes can make big differences. If your tool feels a little bit snappier, you might make two commits instead of one, then six months down the line someone saves half an hour tracking down a bug because the blame messages are more relevant.
JulianMorrison 17y ago
Speed changes your workflow. With slow or fussy source control, you're more likely to do "branches" by just not checking in your changes for awhile. With near-instant source control, you don't feel burdened by making a feature branch, switching, editing and committing a few times, and merging back.
- axod 17y ago
  True, I don't really like using branching/merging as a workflow unless absolutely necessary. So sure, if you're constantly branching and merging all day, then I can see it being a problem. But I'm not convinced branching+merging is really good for your productivity. The other point is that with a distributed system like git, all of the load is on your local machine. With a centralized system like subversion, the server could do the heavy lifting (Wether this happens in practice is another matter). My point is, if you want lightening fast rev control for some reason, probably better to not use distributed.
  - silentbicycle 17y ago
    The flip side is that, with most VC systems, queries about changes or repository history have network latency added. The feedback is near-instant from distributed systems, which keep their info locally. I find it makes a tremendous difference when, say, bisecting an error.
  - DougBTX 17y ago
    But I'm not convinced branching+merging is really good for your productivity. Because branching and merging are slow? I can see this argument getting stuck in something of a rut.
    - axod 17y ago
      No. I prefer to keep things simple, always make sure the source builds, and just develop linearly where possible. I think it makes for cleaner workflow.
      - JulianMorrison 17y ago
        The advantage of having lots of small branches is that you isolate work. You never have the problem of wanting to fix a bug or add some small feature, but having the code all in a mess halfway through a major reorganization. Also it's a lot easier to try something experimental on a branch. If it works, merge it in. If it fails, abandon the branch. Git makes branching and merging fast enough that using them as the default workflow makes sense.
        axod 17y ago
        Yeah I just don't work that way. I work linearly :/
        dasil003 17y ago
        What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete? Sure it's optimal to work linearly, but in the real world things come up. Now if you are looking for a reason to tell stakeholders to suck it up and wait, then poor branching support may help you, but that's a technical solution to a managerial problem. If you're interested in having the most flexibility to solve real world problems, then git's power is indispensable. Hell, you can work linearly all the time, and retroactively convert anything into a branch. Even if you don't need branches. Even if you are the sole developer. Sorry if that's a little harsh, but statements like "My point is, if you want lightening fast rev control for some reason, probably better to not use distributed." smack of willful ignorance. Go use git for a while and then come back and try to say that with a straight face.
Deestan 17y ago
Anything that is part of the programming routine should be severely optimized. Every little bit not only adds up, it often multiplies in big enough projects. In one of our big products, we have several build steps that touch upon the source control systems. 10 second VCS delay X 6 build steps, 1 second lazily written c++-header slowdown X 300 files, etc. and before you know it something that should take 10-15 minutes for a clean build now takes ~1 hour. True story. :( Luckily, enough of us got so annoyed about this that it got fixed after a few weeks of dedicated effort. We now have a constant conscious effort to keep build times down.
- berntb 17y ago
  Thank you for reminding me about compilation time. Now I won't be tempted to go back from scripting language country for a few more years... :-) Edit: I should add that I have very fond memories about my youth and C, too.
  - ido 17y ago
    C++ compiles much slower than many other popular compiled languages, and the more of its "fancy" features you use the slower it compiles. C & Java for example both compile much faster than c++.
  - mrkurt 17y ago
    Most sane projects I've experienced do "builds" even with scripting languages. It's every bit as much of an annoyance to have a bunch of needlessly slow tests as it is to deal with slow compile times.
    - berntb 17y ago
      OK, a point; the pain with compiling languages is the compile cycle where you edit-and-run just local tests, not for the whole system.
- gvb 17y ago
  As Deestan notes, delays have direct multipliers. Beyond that, delays often have indirect multipliers that are even worse. XKCD "Compiling" http://xkcd.com/303/ http://xkcd.com/303/ is funny because we have all done it. If there is a noticeable lag in a development step (VCS operations, compiling, running the program, etc.), it is very likely that the developer will lose concentration and switch to reading email, browsing HN, reading /., BSing with co-workers, etc. This takes the direct delays and turns them into exponential multipliers. The result is that 30 seconds of lag has a high risk of becoming 30 minutes of wasted time.

Agree. If your bottleneck is your source control tool, you're doing something wrong.

by axod 17y ago

Agree. If your bottleneck is your source control tool, you're doing something wrong.

Discussing bottlenecks oversimplifies, it assumes everything goes down one pipeline. Small changes can make big differences. If your tool feels a little bit snappier, you might make two commits instead of one, then six months down the line someone saves half an hour tracking down a bug because the blame messages are more relevant.

JulianMorrison 17y ago

Speed changes your workflow. With slow or fussy source control, you're more likely to do "branches" by just not checking in your changes for awhile. With near-instant source control, you don't feel burdened by making a feature branch, switching, editing and committing a few times, and merging back.

axod 17y ago
True, I don't really like using branching/merging as a workflow unless absolutely necessary. So sure, if you're constantly branching and merging all day, then I can see it being a problem. But I'm not convinced branching+merging is really good for your productivity. The other point is that with a distributed system like git, all of the load is on your local machine. With a centralized system like subversion, the server could do the heavy lifting (Wether this happens in practice is another matter). My point is, if you want lightening fast rev control for some reason, probably better to not use distributed.
- silentbicycle 17y ago
  The flip side is that, with most VC systems, queries about changes or repository history have network latency added. The feedback is near-instant from distributed systems, which keep their info locally. I find it makes a tremendous difference when, say, bisecting an error.
- DougBTX 17y ago
  But I'm not convinced branching+merging is really good for your productivity. Because branching and merging are slow? I can see this argument getting stuck in something of a rut.
  - axod 17y ago
    No. I prefer to keep things simple, always make sure the source builds, and just develop linearly where possible. I think it makes for cleaner workflow.
    - JulianMorrison 17y ago
      The advantage of having lots of small branches is that you isolate work. You never have the problem of wanting to fix a bug or add some small feature, but having the code all in a mess halfway through a major reorganization. Also it's a lot easier to try something experimental on a branch. If it works, merge it in. If it fails, abandon the branch. Git makes branching and merging fast enough that using them as the default workflow makes sense.
      - axod 17y ago
        Yeah I just don't work that way. I work linearly :/
        dasil003 17y ago
        What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete? Sure it's optimal to work linearly, but in the real world things come up. Now if you are looking for a reason to tell stakeholders to suck it up and wait, then poor branching support may help you, but that's a technical solution to a managerial problem. If you're interested in having the most flexibility to solve real world problems, then git's power is indispensable. Hell, you can work linearly all the time, and retroactively convert anything into a branch. Even if you don't need branches. Even if you are the sole developer. Sorry if that's a little harsh, but statements like "My point is, if you want lightening fast rev control for some reason, probably better to not use distributed." smack of willful ignorance. Go use git for a while and then come back and try to say that with a straight face.

Deestan 17y ago

Anything that is part of the programming routine should be severely optimized. Every little bit not only adds up, it often multiplies in big enough projects. In one of our big products, we have several build steps that touch upon the source control systems. 10 second VCS delay X 6 build steps, 1 second lazily written c++-header slowdown X 300 files, etc. and before you know it something that should take 10-15 minutes for a clean build now takes ~1 hour. True story. :( Luckily, enough of us got so annoyed about this that it got fixed after a few weeks of dedicated effort. We now have a constant conscious effort to keep build times down.

berntb 17y ago
Thank you for reminding me about compilation time. Now I won't be tempted to go back from scripting language country for a few more years... :-) Edit: I should add that I have very fond memories about my youth and C, too.
- ido 17y ago
  C++ compiles much slower than many other popular compiled languages, and the more of its "fancy" features you use the slower it compiles. C & Java for example both compile much faster than c++.
- mrkurt 17y ago
  Most sane projects I've experienced do "builds" even with scripting languages. It's every bit as much of an annoyance to have a bunch of needlessly slow tests as it is to deal with slow compile times.
  - berntb 17y ago
    OK, a point; the pain with compiling languages is the compile cycle where you edit-and-run just local tests, not for the whole system.
gvb 17y ago
As Deestan notes, delays have direct multipliers. Beyond that, delays often have indirect multipliers that are even worse. XKCD "Compiling" http://xkcd.com/303/ http://xkcd.com/303/ is funny because we have all done it. If there is a noticeable lag in a development step (VCS operations, compiling, running the program, etc.), it is very likely that the developer will lose concentration and switch to reading email, browsing HN, reading /., BSing with co-workers, etc. This takes the direct delays and turns them into exponential multipliers. The result is that 30 seconds of lag has a high risk of becoming 30 minutes of wasted time.