5 ms·
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
by 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 agoThe 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 agoDude, 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 agoNot 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.