5 ms·

They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion wa

They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion way of doing it.

axod 17y ago
FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.
- lurch_mojoff 17y ago
  I believe that by "superior branching", DannoHung actually ment superior merging. That is something at which SVN is far, far behind DVCSs in general and GIT in particular. Also, my experience, as non-representative as it is, has shown that cheap branching with efficient merging results in much less of a mess than everybody playing in the same sandbox and inevitably kicking everybody else's sand castles.
  - axod 17y ago
    > "everybody playing in the same sandbox and inevitably kicking everybody else's sand castles." That just points to poor collaboration management etc though. If people don't work together properly, you're just delaying problems until people merge anyway.
    - cdavid 17y ago
      The big advantage of branches is to allow to break your commits into smaller things. When working on two new features which takes many commits, if you work on the same branch, the history becomes inter winded, and that's a nightmare to understand if you need to go back (or find regression). With branches that are pulled into a public reference branch, you are guaranteed to get a workable, coherent and consistent state. Without branches, what happens is either broken trunk or giant commits, both often worse than the (real) complexity brought by branch. The fact that DVCS allows for less rigid management alo explains why DVCS became popular so quickly in open source, I think (where the kind of collaboration managements you suggest does not scale very well).
      - axod 17y ago
        > "Without branches, what happens is either broken trunk or giant commits, both often worse than the (real) complexity brought by branch." Or you do your development in a way that doesn't break the build, and do it in several steps. For example, just build new code that can be specified to be used at runtime, then when it works just like the existing default code, switch it over (Effectively doing your own branch).
        DannoHung 17y ago
        Dude, you're talking about expending extra effort and thought to be able to do something cleanly which the new tool lets you do effortlessly and mindlessly all to avoid something that the new tool is EXCELLENT at.
    - lurch_mojoff 17y ago
      Not necessarily so. As I said, my experience may not be representative of the most common workflows, but in the company I'm working for people often work on experimental or tangential stuff but at the same time they want their changes to keep pace with the work on the main line. I that case they can't afford to sully the trunk and at the same time, because merging back a branch is a major pain, they can't fork off a branch, unless it is a significant enough chunk of functionality or code they are changing. No amount of "collaboration management" is going to make the situation any better, because all options result in some amount of pain for someone, pain makes people touchy, and touchiness makes people not work together properly. Just as you believe that a proper social structure and sufficiently clear conventions can overcome deficiencies in software, I believe the oposite - the capabilities and limitations of software can enforce certain patterns of behavior. And in my experience DVCSs end up having more of a positive effect on the development process.
- MrMatt 17y ago
  Branching was a pain for me when using SVN - far too much hassle to keep on top of it all; All branches are visible to everyone and merging between them was slow. With Git, branching is simple and really fast. It can also be done in such a way as to prevent your own personal development and feature branches from making it back into the central repo. I've also found that cherry picking commits between branches and squishing small commits help me maintain the cleanliness of our repos (At no point in the history of our central repo is there half of a new feature or fix).
- grogers 17y ago
  Except that in subversion, branching is a great way to lose revision history. I think this is partly fixed with the merge tracking features in the more recent subversion, but in git it is simple - it just works like you'd expect.
- natrius 17y ago
  Maybe I'm Doing It Wrong, but when I want to tag a release (or create a branch) in subversion, I have to make a copy of the entire codebase. When I want to tag a release in git, it just creates a pointer to a revision. It's far less annoying for the next person who needs to checkout the code.
- jedbrown 17y ago
  The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once the excuses run out and they have to be done. Distributed SCMs recognize that branching is necessary, but actually provide the tools to make merging easy. Once merging is easy, branching doesn't look bad any more.
  - axod 17y ago
    It still looks bad to me. I want 1 codebase, developed linearly. Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess. I much prefer doing branches in the source code (If that makes sense). For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.
    - davidw 17y ago
      I use branches in Hecl to play around with experimental features. These are things that I want to keep around for a while, hack on, but that are not ready to be in Hecl proper. If I had to wait for a yes/no on those features to go on with other things, it would slow things down.
    - jerf 17y ago
      "I want 1 codebase, developed linearly." Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end. Except you can trivially have multiple of these things going at a time. I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git might affect workflow to people who actually know how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)
- kennu 17y ago
  Branching in Subversion is easy, it's the merging part that's difficult. That's because branches in Subversion are just copied folders that it tries to keep in sync with some magic "glued on" metadata attributes. (At least they were the last time I checked.) In Git, branches are an inherent part of the repository graph structure. So the relationships of branches and merges are very low level and stable and work quite reliably in all situations. Because of this I trust Git more for branching/merging.
- gommm 17y ago
  I used to think like you back when using svn... Now I think that when using svn, branching causes a mess and for that reason is bad... But, it's amazingly convenient and simple to use with git
  - axod 17y ago
    I didn't mean that I believe branches in svn are a mess. I mean that the concept of using branches IMHO is messy and should be avoided. I just don't like that workflow at all. I don't think it's good for productivity.
- cdavid 17y ago
  There are many situations where branches are the standard, conventional way of doings things: release managements, legacy development. Making branch hard does not make much sense - svn (with maybe cvs) are the only systems which make branch almost unusable. Every other system (including proprietary, non distributed ones) handle branch correctly. Git made popular the use of branches for almost everything, but branches have been used way before DVCS became popular. It just happened to be that besides cvs/svn, all the non peculiar open source systems are DVCS, but working merge caps and branch managements are not specific to DVCS (but DVCS would be unusable without it).

They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion way of doing it.

axod 17y ago

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

lurch_mojoff 17y ago
I believe that by "superior branching", DannoHung actually ment superior merging. That is something at which SVN is far, far behind DVCSs in general and GIT in particular. Also, my experience, as non-representative as it is, has shown that cheap branching with efficient merging results in much less of a mess than everybody playing in the same sandbox and inevitably kicking everybody else's sand castles.
- axod 17y ago
  > "everybody playing in the same sandbox and inevitably kicking everybody else's sand castles." That just points to poor collaboration management etc though. If people don't work together properly, you're just delaying problems until people merge anyway.
  - cdavid 17y ago
    The big advantage of branches is to allow to break your commits into smaller things. When working on two new features which takes many commits, if you work on the same branch, the history becomes inter winded, and that's a nightmare to understand if you need to go back (or find regression). With branches that are pulled into a public reference branch, you are guaranteed to get a workable, coherent and consistent state. Without branches, what happens is either broken trunk or giant commits, both often worse than the (real) complexity brought by branch. The fact that DVCS allows for less rigid management alo explains why DVCS became popular so quickly in open source, I think (where the kind of collaboration managements you suggest does not scale very well).
    - axod 17y ago
      > "Without branches, what happens is either broken trunk or giant commits, both often worse than the (real) complexity brought by branch." Or you do your development in a way that doesn't break the build, and do it in several steps. For example, just build new code that can be specified to be used at runtime, then when it works just like the existing default code, switch it over (Effectively doing your own branch).
      - DannoHung 17y ago
        Dude, you're talking about expending extra effort and thought to be able to do something cleanly which the new tool lets you do effortlessly and mindlessly all to avoid something that the new tool is EXCELLENT at.
  - lurch_mojoff 17y ago
    Not necessarily so. As I said, my experience may not be representative of the most common workflows, but in the company I'm working for people often work on experimental or tangential stuff but at the same time they want their changes to keep pace with the work on the main line. I that case they can't afford to sully the trunk and at the same time, because merging back a branch is a major pain, they can't fork off a branch, unless it is a significant enough chunk of functionality or code they are changing. No amount of "collaboration management" is going to make the situation any better, because all options result in some amount of pain for someone, pain makes people touchy, and touchiness makes people not work together properly. Just as you believe that a proper social structure and sufficiently clear conventions can overcome deficiencies in software, I believe the oposite - the capabilities and limitations of software can enforce certain patterns of behavior. And in my experience DVCSs end up having more of a positive effect on the development process.
MrMatt 17y ago
Branching was a pain for me when using SVN - far too much hassle to keep on top of it all; All branches are visible to everyone and merging between them was slow. With Git, branching is simple and really fast. It can also be done in such a way as to prevent your own personal development and feature branches from making it back into the central repo. I've also found that cherry picking commits between branches and squishing small commits help me maintain the cleanliness of our repos (At no point in the history of our central repo is there half of a new feature or fix).
grogers 17y ago
Except that in subversion, branching is a great way to lose revision history. I think this is partly fixed with the merge tracking features in the more recent subversion, but in git it is simple - it just works like you'd expect.
natrius 17y ago
Maybe I'm Doing It Wrong, but when I want to tag a release (or create a branch) in subversion, I have to make a copy of the entire codebase. When I want to tag a release in git, it just creates a pointer to a revision. It's far less annoying for the next person who needs to checkout the code.
jedbrown 17y ago
The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once the excuses run out and they have to be done. Distributed SCMs recognize that branching is necessary, but actually provide the tools to make merging easy. Once merging is easy, branching doesn't look bad any more.
- axod 17y ago
  It still looks bad to me. I want 1 codebase, developed linearly. Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess. I much prefer doing branches in the source code (If that makes sense). For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.
  - davidw 17y ago
    I use branches in Hecl to play around with experimental features. These are things that I want to keep around for a while, hack on, but that are not ready to be in Hecl proper. If I had to wait for a yes/no on those features to go on with other things, it would slow things down.
  - jerf 17y ago
    "I want 1 codebase, developed linearly." Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end. Except you can trivially have multiple of these things going at a time. I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git might affect workflow to people who actually know how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)
kennu 17y ago
Branching in Subversion is easy, it's the merging part that's difficult. That's because branches in Subversion are just copied folders that it tries to keep in sync with some magic "glued on" metadata attributes. (At least they were the last time I checked.) In Git, branches are an inherent part of the repository graph structure. So the relationships of branches and merges are very low level and stable and work quite reliably in all situations. Because of this I trust Git more for branching/merging.
gommm 17y ago
I used to think like you back when using svn... Now I think that when using svn, branching causes a mess and for that reason is bad... But, it's amazingly convenient and simple to use with git
- axod 17y ago
  I didn't mean that I believe branches in svn are a mess. I mean that the concept of using branches IMHO is messy and should be avoided. I just don't like that workflow at all. I don't think it's good for productivity.
cdavid 17y ago
There are many situations where branches are the standard, conventional way of doings things: release managements, legacy development. Making branch hard does not make much sense - svn (with maybe cvs) are the only systems which make branch almost unusable. Every other system (including proprietary, non distributed ones) handle branch correctly. Git made popular the use of branches for almost everything, but branches have been used way before DVCS became popular. It just happened to be that besides cvs/svn, all the non peculiar open source systems are DVCS, but working merge caps and branch managements are not specific to DVCS (but DVCS would be unusable without it).