[tentonova]

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.

[kscaldef]

This still feels like the sort of statement that comes from having not worked with a (D)VCS that does branching well. There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix.

What you're talking about seems to be multiple, long-running development or release branches. Those are hard to manage and generally a bad idea in any VCS. But, with a system like Git, you don't tend to have long-lived divergent development branches. Typical branch lifetimes are more like hours or days, rather than weeks or months. There are exceptions, but by-and-large, branches are just used differently in git.

[tentonova]

This still feels like the sort of statement that comes from having not worked with a (D)VCS that does branching well.

I've worked with both git and hg.

There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix.

What's the value of this private branch beyond simply committing to the actual branch?

If it's just a bug fix, how big can it be?

If it's more than a bug fix, why am I hiding this code from the team by implementing it on a private, local, non-backed up, non-code-reviewed, non-centralized branch?

Typical branch lifetimes are more like hours or days, rather than weeks or months. There are exceptions, but by-and-large, branches are just used differently in git.

Why wouldn't I just commit this work incrementally to the actual upstream branch, rather than hiding it for "hours or days" from the rest of the team?

[kscaldef]

Reading this comment and your other comments in this discussion, I think you have some issues which have nothing to do with what version control system is being used. While you keep talking about "hiding code" and "hindering communication" and "cowboy coding", I think about keeping the history of our codebase well-organized so that you can understand the evolution of a single feature, so that commits are logically ordered, so that unrelated changes don't get lumped together because it was the easy thing to do.

To quickly comment on a couple of your other concerns, my local hard-drive is backed up, so that's irrelevant; and I personally feel that code review at the level of individual commits has very little value, and you should instead be reviewing complete feature implementations.

[dasil003]

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]

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.

[dasil003]

I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here.

Merging.

Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.

If you're using the limitations of your VCS to manage team communication then you have bigger problems. The obvious analog to the "problem" you mention is people not checking in code because it's not ready yet. Maybe you think this is better because you only want deployable software in your main branch, but for large features that makes the history opaque and leaves your developer effectively without any of the benefits of version control while they are working on the large feature.

Frankly, a lot of the arguments against DVCS smack of the same sort of ignorance that the Java zealots were leveraging against Ruby back when Rails started picking up steam in 2005/2006. There's this fear that powerful features will lead to chaos and are in effect too powerful to be used safely. And the reality is that yes, in environments truly incompetent programmers work, there's definitely a strong argument to be made for limiting the damage they can do. But I think the past few years have borne out the fact that mediocre and merely-competent programmers can make strong use of these tools without leading to disaster.

[tentonova]

Merging.

Subversion 1.5, released in June of 2008, supports merge tracking.

If you're using the limitations of your VCS to manage team communication then you have bigger problems.

A simple but sufficiently powerful solution leads to simplified communication. If you're using the complexity of your VCS to hinder team communication and support cowboy coding, then you have bigger problems.

Frankly, a lot of the arguments against DVCS smack of the same sort of ignorance that the Java zealots were leveraging against Ruby back when Rails started picking up steam in 2005/2006 ... But I think the past few years have borne out the fact that mediocre and merely-competent programmers can make strong use of these tools without leading to disaster.

Nobody (intelligent) said there'd be disaster because of the "powerful features", just that operating in that manner would be more expensive than the much simpler alternatives.

Expending more effort with more powerful tools isn't actually an improvement, it's just busy-work -- constantly working on your muscle car instead of driving it.

[dasil003]

If you're using the complexity of your VCS to hinder team communication and support cowboy coding, then you have bigger problems.

This is a blub attitude plain and simple.

[prodigal_erik]

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.