4 ms·

> Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many wa

> Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways. The benefits come at a cost though (I say this as someone who works with both). For many environments, a centralized VCS is all you need. Making it distributed just because that's a popular thing to do isn't necessarily always a good idea. It complicates workflows because now you have to have multiple version control systems which interact with eachother in far more complex ways. You don't want to go down that path if you don't need to. Now, despite the costs, there are many advantages to git. These include an ability to effectively treat your local repo as a master for a client. Also DVCS's scale to a larger number of developers more than traditional VCS's and git has advantages there too. BTW. one thing I find to be a killer feature of github is the fact that it offers you svn access to git repos, which can be really, really nice.

chris_wot 13y ago
Well, no. If you have a centralized git server (can be done), then you have the following workflow: 1. Make your changes, branch, do whatever you want to do. 2. Commit the changes to your repo. 3. Push your changes to the remote repo. 4. When you want to get other's changes, pull those changes. Heck, do a git pull -r if you want to rebase them. That is really not that complicated. However, you get the benefits of a local copy. So not what I'd really call totally distributed, but I can't see any downsides to this.
- einhverfr 13y ago
  > That is really not that complicated. It's still twice as many steps. Well, probably more if you count git add before every commit. Also a big problem for me is the necessity of a git add * before a commit, which effectively requires a lot of management of .gitignore so you don't get things like the Makefile.old getting committed. Keep in mind, all of this is process overhead, an opportunity to make mistakes, and effort (including tracking/fixing the mistakes) that could be spent programming. There are downsides. As I say, I do a fair bit with both and to be honest I am not that enthusiastic about git over svn. It's really good in some cases. However it isn't always better. Sometimes simpler tools are better.
  - pjc50 13y ago
    "git add -u" behaves better. Personally (as a near-beginner) I have no end of trouble with the push/pull workflow. You can't pull if you have files edited, but you can't push if you're behind. 'git stash' makes this a bit less painful.
pjc50 13y ago
Indeed - which system is best depends on your workflow. For small to medium teams structured in a top-down business way, svn is easier to understand. git generates a lot more merging (every pull is a merge). A distributed VCS is very useful if you have a distributed team. If you don't, the distributed aspect is simply not very relevant.
nimblegorilla 13y ago
> The benefits come at a cost though (I say this as someone who works with both). For many environments, a centralized VCS is all you need. I'm having a hard time understanding what these extra "costs" are. I haven't used SVN in a while, but I think the only extra cost is an extra command to push your changes to a repository. Meanwhile, the advantages of a distributed VCS are huge. Even if everyone is developing on the same LAN it seems beneficial to have a DVCS. I've been on multiple projects where the centralized VCS goes down for a day or even a week. In that scenario everyone has to stop committing changes. Sharing changes with a coworker now requires making a patch file or some other cumbersome operation. I can't think of a situation where a centralized VCS is better for any team.
- einhverfr 13y ago
  I just find I end up spending quite a bit more time fighting with git than I do svn. It may be anecdotal, but I find my workflows are far more error prone in git, and consequently they take a lot more overhead to ensure they are right. What you say might be true by at least accepted theory, and it is true that command-line git (and git has a reputation of a bad command line) is the only dcvs I have worked with but I don't see a way around the fact that since you allow more complexity in interactions between repos, this is going to have more overhead. Even you seem to acknowledge twice as many commands for version control management for the simplest cases. I am not really anti-git even. As I say I use it for some things. But I am not at all convinced dvcs is always the right tool for the job.
  - nimblegorilla 13y ago
    > Even you seem to acknowledge twice as many commands for version control management for the simplest cases. Well, I didn't really say that regarding the simplest cases. There is one extra command to get something into the central repository, but basic checkouts and updates from the repository are still one command. I've gone through the "fighting" with git stage, but it was more because I was trying to use concepts that aren't even possible with SVN rather than that git makes things more complicated.

chris_wot 13y ago

Well, no. If you have a centralized git server (can be done), then you have the following workflow: 1. Make your changes, branch, do whatever you want to do. 2. Commit the changes to your repo. 3. Push your changes to the remote repo. 4. When you want to get other's changes, pull those changes. Heck, do a git pull -r if you want to rebase them. That is really not that complicated. However, you get the benefits of a local copy. So not what I'd really call totally distributed, but I can't see any downsides to this.

einhverfr 13y ago
> That is really not that complicated. It's still twice as many steps. Well, probably more if you count git add before every commit. Also a big problem for me is the necessity of a git add * before a commit, which effectively requires a lot of management of .gitignore so you don't get things like the Makefile.old getting committed. Keep in mind, all of this is process overhead, an opportunity to make mistakes, and effort (including tracking/fixing the mistakes) that could be spent programming. There are downsides. As I say, I do a fair bit with both and to be honest I am not that enthusiastic about git over svn. It's really good in some cases. However it isn't always better. Sometimes simpler tools are better.
- pjc50 13y ago
  "git add -u" behaves better. Personally (as a near-beginner) I have no end of trouble with the push/pull workflow. You can't pull if you have files edited, but you can't push if you're behind. 'git stash' makes this a bit less painful.

pjc50 13y ago

Indeed - which system is best depends on your workflow. For small to medium teams structured in a top-down business way, svn is easier to understand. git generates a lot more merging (every pull is a merge). A distributed VCS is very useful if you have a distributed team. If you don't, the distributed aspect is simply not very relevant.

nimblegorilla 13y ago

> The benefits come at a cost though (I say this as someone who works with both). For many environments, a centralized VCS is all you need. I'm having a hard time understanding what these extra "costs" are. I haven't used SVN in a while, but I think the only extra cost is an extra command to push your changes to a repository. Meanwhile, the advantages of a distributed VCS are huge. Even if everyone is developing on the same LAN it seems beneficial to have a DVCS. I've been on multiple projects where the centralized VCS goes down for a day or even a week. In that scenario everyone has to stop committing changes. Sharing changes with a coworker now requires making a patch file or some other cumbersome operation. I can't think of a situation where a centralized VCS is better for any team.

einhverfr 13y ago
I just find I end up spending quite a bit more time fighting with git than I do svn. It may be anecdotal, but I find my workflows are far more error prone in git, and consequently they take a lot more overhead to ensure they are right. What you say might be true by at least accepted theory, and it is true that command-line git (and git has a reputation of a bad command line) is the only dcvs I have worked with but I don't see a way around the fact that since you allow more complexity in interactions between repos, this is going to have more overhead. Even you seem to acknowledge twice as many commands for version control management for the simplest cases. I am not really anti-git even. As I say I use it for some things. But I am not at all convinced dvcs is always the right tool for the job.
- nimblegorilla 13y ago
  > Even you seem to acknowledge twice as many commands for version control management for the simplest cases. Well, I didn't really say that regarding the simplest cases. There is one extra command to get something into the central repository, but basic checkouts and updates from the repository are still one command. I've gone through the "fighting" with git stage, but it was more because I was trying to use concepts that aren't even possible with SVN rather than that git makes things more complicated.