4 ms·

> I am sorry to tell you, but you are plain wrong! Git is better. Please, do elaborate! In detail, why is git better than subversion if all I need is a central

by kahawe 15y ago

> I am sorry to tell you, but you are plain wrong! Git is better. Please, do elaborate! In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. No distributed or remote or on-the-go development, no forks. > SVN embraces a workflow that is inferior. It is different but what exactly makes it inferior?

fuzzix 15y ago
"Please, do elaborate! In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. No distributed or remote or on-the-go development, no forks" You describe my environment almost exactly. I am pushing for a git migration mostly for the low-overhead branching/merging as I can have multiple discrete tasks on a given project which need to be rolled out individually.
- RyanMcGreal 15y ago
  Don't forget speed. Git is fast.
- deleted 15y ago
  [deleted]
yummyfajitas 15y ago
In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. I was in exactly this situation at my last job (minus the same room, I was stuck in a separate office). In spite of the main source repo being SVN, we all used git-svn as our client. The main benefit is that git makes it easier to create clean commits and push them to trunk. E.g., I want to make module Foo, and use it in Bar. I can use git as I go, building module Foo incrementally over 5 commits (none of which has sufficient quality to go into trunk). Then I can do 5 more commits which integrate Foo into Bar. So my individual history is tracked while I'm developing. If, while building Bar, I make a bugfix to foo, I can commit it. So logically, my commits look like: 101-104 Work on Foo 105-107 Work on Bar 108 Bug fix on Foo 109-111 Finish work on Bar When it comes time to push to trunk, I can rebase 101-104 + 108 into one clean patch, "Built module foo", and 105-107 + 109-111 into "Incorporate module foo into bar". Then I eventually push these into the main repo. Further, if I'm working on this with someone else, we can use git to track work between the two of us without committing to mainline.
- deleted 15y ago
  [deleted]
- spiffytech 15y ago
  This workflow sounds like it could be replaced by creating a feature branch, developing the feature there, then merging the branch back into trunk when the feature is complete. This can be implemented in ordinary SVN, without git or git-svn.
  - yummyfajitas 15y ago
    Almost, but not quite. As far as I know, svn doesn't support rebase -i. Also, part of the point of the workflow is to make sure all commits to the official repo are clean code. Using a feature branch means that the official repo contains commits like "Halfassed implementation of foo, joe take a look at it".
EdiX 15y ago
> Please, do elaborate! In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. No distributed or remote or on-the-go development, no forks. Because with svn you end up having dirty working directories that go uncommitted for days because committing would break the build, as a result: 1. Everyone ends up making a second working directory because the first one they have is dirty with changes they can't yet commit and they need to make a quick change 2. Those dirty working directories are branches in practice, even if svn doesn't call them that, they are just dealt with with inferior tools. Also: cherry picking commits from a branch into another branch isn't as easy, making a new repository isn't as easy, git is way faster at (almost?) everything (including large binary files), and being able to check the history when you are not in the office or connected to the VPN is nice. However, I agree that the conceptual model behind DVCS is harder to understand, significantly harder, svn can be good enough especially for a small, local team.
- nirvdrum 15y ago
  SVN has branches, too. The problem it had was with merge-tracking and that's about when everyone hopped over to git (myself included). But that hasn't been an issue for a couple years now. By all means, stick with git if you prefer it, but release some of the older criticisms as they've been addressed by the SVN team.
  - EdiX 15y ago
    > SVN has branches, too. I don't think I have said it doesn't
    - nirvdrum 15y ago
      You certainly implied a branch-free workflow. Otherwise why would you have a dirty local workspace and multiple checkouts? And why would committing break a build? I'm unaware of any CI server configured to build every branch in the SVN tree.

by kahawe 15y ago

fuzzix 15y ago

"Please, do elaborate! In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. No distributed or remote or on-the-go development, no forks" You describe my environment almost exactly. I am pushing for a git migration mostly for the low-overhead branching/merging as I can have multiple discrete tasks on a given project which need to be rolled out individually.

RyanMcGreal 15y ago
Don't forget speed. Git is fast.
deleted 15y ago
[deleted]

yummyfajitas 15y ago

In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. I was in exactly this situation at my last job (minus the same room, I was stuck in a separate office). In spite of the main source repo being SVN, we all used git-svn as our client. The main benefit is that git makes it easier to create clean commits and push them to trunk. E.g., I want to make module Foo, and use it in Bar. I can use git as I go, building module Foo incrementally over 5 commits (none of which has sufficient quality to go into trunk). Then I can do 5 more commits which integrate Foo into Bar. So my individual history is tracked while I'm developing. If, while building Bar, I make a bugfix to foo, I can commit it. So logically, my commits look like: 101-104 Work on Foo 105-107 Work on Bar 108 Bug fix on Foo 109-111 Finish work on Bar When it comes time to push to trunk, I can rebase 101-104 + 108 into one clean patch, "Built module foo", and 105-107 + 109-111 into "Incorporate module foo into bar". Then I eventually push these into the main repo. Further, if I'm working on this with someone else, we can use git to track work between the two of us without committing to mainline.

deleted 15y ago
[deleted]
spiffytech 15y ago
This workflow sounds like it could be replaced by creating a feature branch, developing the feature there, then merging the branch back into trunk when the feature is complete. This can be implemented in ordinary SVN, without git or git-svn.
- yummyfajitas 15y ago
  Almost, but not quite. As far as I know, svn doesn't support rebase -i. Also, part of the point of the workflow is to make sure all commits to the official repo are clean code. Using a feature branch means that the official repo contains commits like "Halfassed implementation of foo, joe take a look at it".

EdiX 15y ago

> Please, do elaborate! In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. No distributed or remote or on-the-go development, no forks. Because with svn you end up having dirty working directories that go uncommitted for days because committing would break the build, as a result: 1. Everyone ends up making a second working directory because the first one they have is dirty with changes they can't yet commit and they need to make a quick change 2. Those dirty working directories are branches in practice, even if svn doesn't call them that, they are just dealt with with inferior tools. Also: cherry picking commits from a branch into another branch isn't as easy, making a new repository isn't as easy, git is way faster at (almost?) everything (including large binary files), and being able to check the history when you are not in the office or connected to the VPN is nice. However, I agree that the conceptual model behind DVCS is harder to understand, significantly harder, svn can be good enough especially for a small, local team.

nirvdrum 15y ago
SVN has branches, too. The problem it had was with merge-tracking and that's about when everyone hopped over to git (myself included). But that hasn't been an issue for a couple years now. By all means, stick with git if you prefer it, but release some of the older criticisms as they've been addressed by the SVN team.
- EdiX 15y ago
  > SVN has branches, too. I don't think I have said it doesn't
  - nirvdrum 15y ago
    You certainly implied a branch-free workflow. Otherwise why would you have a dirty local workspace and multiple checkouts? And why would committing break a build? I'm unaware of any CI server configured to build every branch in the SVN tree.