3 ms·

>> "Anyone got any actual data?" Is the SPEED of any revision control system ever an issue? To anyone? Surely it's 'fast enough that it doesn't matter' vs 'fas

by axod 17y ago

>> "Anyone got any actual data?" Is the SPEED of any revision control system ever an issue? To anyone? Surely it's 'fast enough that it doesn't matter' vs 'fast enough that it doesn't matter'

masklinn 17y ago
> Is the SPEED of any revision control system ever an issue? Yes, darcs used to have (and probably still has, though to a lesser level) an issue with merge times blowing up exponentially. Anyway stevejohnson took issue with the statement that Mercurial performed roughly on part with Git, you might want to take the issue up to him not davidw.
rictic 17y ago
I'm not sure about git vs hg, but I'd definitely say that the speed of git is a win vs svn. For example, running status to see the state of the working directory. With svn it takes a couple of seconds on small repositories, and it can easily climb above ten seconds on larger repos. With git it very rarely rises above a second, even with a cold disk cache. The difference in speed is large enough that I find myself running "git status" far, far more often than I ever ran "svn status". A more dramatic example is 'git bisect' which, when given a command, it will do a binary search on the repository to find the commit which caused that command to begin to fail (return an exit code of something other than 0). Speed is a feature.
dlsspy 17y ago
Yes, when a command takes a couple seconds to perform, you don't consider doing it unless you have a really good reason. Classic hg branching came into different forms: 1) a tree clone and 2) the hg "branch" commands. 1 can be very slow on a large tree and can often require you reconfigure your tools to go look in a new place. 2 is permanent. Your code now forever references the name of a branch so you have to stop and think about whether it's really the right thing to do. In either case, anything that requires me to stop and consider the cost of an operation makes the operation less valuable. Where that cost kicks in varies for people. Is it minutes? Seconds? As a former perforce user, there were definitely plenty of things I wouldn't do there because they weren't instant. In git, I tend to make decisions based solely on my desired outcome.

by axod 17y ago

>> "Anyone got any actual data?" Is the SPEED of any revision control system ever an issue? To anyone? Surely it's 'fast enough that it doesn't matter' vs 'fast enough that it doesn't matter'

masklinn 17y ago

> Is the SPEED of any revision control system ever an issue? Yes, darcs used to have (and probably still has, though to a lesser level) an issue with merge times blowing up exponentially. Anyway stevejohnson took issue with the statement that Mercurial performed roughly on part with Git, you might want to take the issue up to him not davidw.

rictic 17y ago

I'm not sure about git vs hg, but I'd definitely say that the speed of git is a win vs svn. For example, running status to see the state of the working directory. With svn it takes a couple of seconds on small repositories, and it can easily climb above ten seconds on larger repos. With git it very rarely rises above a second, even with a cold disk cache. The difference in speed is large enough that I find myself running "git status" far, far more often than I ever ran "svn status". A more dramatic example is 'git bisect' which, when given a command, it will do a binary search on the repository to find the commit which caused that command to begin to fail (return an exit code of something other than 0). Speed is a feature.

dlsspy 17y ago

Yes, when a command takes a couple seconds to perform, you don't consider doing it unless you have a really good reason. Classic hg branching came into different forms: 1) a tree clone and 2) the hg "branch" commands. 1 can be very slow on a large tree and can often require you reconfigure your tools to go look in a new place. 2 is permanent. Your code now forever references the name of a branch so you have to stop and think about whether it's really the right thing to do. In either case, anything that requires me to stop and consider the cost of an operation makes the operation less valuable. Where that cost kicks in varies for people. Is it minutes? Seconds? As a former perforce user, there were definitely plenty of things I wouldn't do there because they weren't instant. In git, I tend to make decisions based solely on my desired outcome.