This looks fine if you only spend a few minutes in the 2-3-2-3 loop. On the other hand, if you're in a very busy team and there are refactorings going on (and when shouldn't there be?) then you will want to have a loop from 3 to 1 pretty darned often (at LEAST a handful of times a day).
At step 1, "For a while" should mean "if a couple of commits have been made by coworkers."
The problem I have with mercurial is that the process of pull, merge, commit is too cumbersome. I have coworkers who swear by rebase, and others who have been bitten enough that they're scared to death to use rebase, and instead pile up the "merge" commits.
There needs to be some kind of change made, if only to fix rebase, because this work flow is broken for active, productive, agile teams.
Wouldn't an active, productive, agile team simply move over to a tool that was more fitting to their needs once they determine the tool used in their current course of action wasn't fitting?
ReplyDelete>> The problem I have with mercurial is that the process of pull, merge, commit is too cumbersome.
ReplyDeleteWhy? I'm a git user but the workflow is the same.
With the right client tool (GitExtensions in my case) these operations are fast and easy. Therefore my question: why cumbersome?
@nick: We don't know that the tool is the problem. Besides, they came over from StarTeam, so EVERY version control system seems pretty darned easy and reliable by comparison. ;-)
ReplyDelete>> if only to fix rebase
ReplyDeleteI don't know of any issues with rebase (at least compared to merge). Any specific examples?
>> The problem I have with mercurial is that the process of pull, merge, commit is too cumbersome.
One command to pull, merge, and rebase:
hg pull --rebase
Or in TortoiseHg set your "Post Pull Behavior" to Rebase.
Sounds like good stuff to try when I'm back in mercurial land. I've been entirely in git and a few other old-school VCSs lately, but look forward to trying.
ReplyDeleteI'll let you know what I learn. Thanks for answering the challenge.
Tim