Mark Mielke wrote:
> On 01/07/2010 04:42 AM, Branko Čibej wrote:
>> Mark Mielke wrote:
>>
>>> The model is a bit easier to implement in ClearCase and GIT, since
>>> these are both effectively the working copy is a different stream from
>>> the parent whereas Subversion designer work flows tend to work
>>> directly on "trunk".
>>>
>> In both ClearCase and GIT (and more so in ClearCase) you pay for it by
>> requiring "someone" do constantly merge stuff to some "stable" mainline.
>> Moreover, the per-developer branch model is just one way of using
>> ClearCase and IMHO one of the more broken recommendations.
>>
>
> ClearCase on its own is nearly useless as an SCM. For those that don't
> know ClearCase, I simplified it to "a sensible and mature wrapper
> developed around ClearCase". In this case, a sensible and mature
> wrapper does not require "somebody" to do constant merging any more
> than Subversion requires the working copy to be merged with HEAD. It's
> a single "commit" operation which, and the commit handles the merge.
>
> In our case, it happens to be called "deliver". The deliver is most
> similar to "merge --reintegrate", only it always works, and can be
> done reproducibly.
Sorry, I didn't quite parse that. are you saying that you can reliably
automate merging and conflict resolution? 'Cos I don't buy that. You can
automate it maybe 95% of the time, depending on how much overlap you
have; but the last 5% is always manual, unless you can also automate all
of software development.
And when you come down to that, there's no real difference between your
"wrapped-clearcase" and Subversion's "update-modify-merge" on a single
branch.
[...]
> To prove this, we have developers on Subversion today who make the
> SAME mistake developers on other systems such as GIT or ClearCase with
> side streams do. That is, they'll work in isolation for three months,
> and then try and commit. Under Subversion today, they do a checkout,
> work in isolation for three months, and then try and update and commit.
But that has nothing to do with the version control system you use. as
you say here:
> This usually fails and they expect us to fix it for them. They worked
> on a "side stream" called the Subversion working copy, and their work
> diverged from trunk for too long to allow easily merging their changes
> back. They should have updated frequently, or in GIT they should have
> "git pull"ed frequently, or in ClearCase/UCM they should have
> "rebase"d frequently. It's the exact same concept. Subversion has not
> solved the problem by limiting people to one off-stream commit -
> they've just encouraged a shorter life cycle by limiting the
> capabilities of the working copy.
I don't understand how you propose to fix developers by changing a tool.
Forbidding mixed revision working copies (e.g., but making every commit
an implicit update) isn't going to help if your developer only commits
once every two weeks. The only thing that will help in the long run is
* educating your developers
* having a proper CM (branching, etc.) policy in place
* educating your developers, and
* educating your developers
Good support for merging is essential, yes; tool performance is
important, yes; but neither is a replacement for doing things right.
I know from bitter experience that some people simply are unable or
refuse to learn to co-operate, but that's a "management" problem and no
amount of tweaking your toolset and processes is going to help there.
-- Brane
Received on 2010-01-07 20:12:39 CET