5 ms·

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

by 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.
      - tentonova 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? I've always worked to constrain non-linear development to the absolute minimum required because the technical costs are easily dwarfed by the human communication overhead and inherent organizational complexity engendered in multiple disparate branches of development.
        dasil003 17y ago
        Of course, but that's irrelevant to the utility of git branches. In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. In git though, branches are most commonly used within one developer's workflow. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to.
        tentonova 17y ago
        In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. svn cp ^/trunk ^/branches/tentonova-bugfix-x svn co ^/branches/tentonova ~/branch I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to. Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.
        prodigal_erik 17y ago
        We do that, and I will say that svnmerge.py doesn't work very well with older versions of svn. A common failure mode is when you merge from trunk to rebase a dev branch and find a conflict, your edits to resolve it are automatically ignored and not reflected back to trunk, and any overlapping edits you make later will eventually cause new conflicts when you finally go to trunk. Apparently the new svn:mergeinfo property helps, but we haven't migrated at work so I don't know how well.

by 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.
    - tentonova 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? I've always worked to constrain non-linear development to the absolute minimum required because the technical costs are easily dwarfed by the human communication overhead and inherent organizational complexity engendered in multiple disparate branches of development.
      - dasil003 17y ago
        Of course, but that's irrelevant to the utility of git branches. In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. In git though, branches are most commonly used within one developer's workflow. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to.
        tentonova 17y ago
        In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. svn cp ^/trunk ^/branches/tentonova-bugfix-x svn co ^/branches/tentonova ~/branch I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to. Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.
        prodigal_erik 17y ago
        We do that, and I will say that svnmerge.py doesn't work very well with older versions of svn. A common failure mode is when you merge from trunk to rebase a dev branch and find a conflict, your edits to resolve it are automatically ignored and not reflected back to trunk, and any overlapping edits you make later will eventually cause new conflicts when you finally go to trunk. Apparently the new svn:mergeinfo property helps, but we haven't migrated at work so I don't know how well.