Mark Mielke wrote:
> On 01/07/2010 02:11 PM, Branko Čibej wrote:
>> 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.
>>
>
> Automatic merging and conflict resolution even across renames works
> extremely well. When it fails, something similar to TortoiseUDiff
> comes up to help resolve the situation. It isn't perfect - but it is
> definitely better than Subversion 1.6 today. I haven't decided whether
> GIT is better or worse than what we have today under ClearCase - they
> seem to be do different portions of that last 5%.
>
>> 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.
>>
>
> Subversion's model is more limited (only one commit per working copy
> for example, and no ability to save changes at intervals), but yes I
> agree and this was one of my points. Subversion relies on automatic
> merges today to be usable, so it's not exactly a horror as a model.
> It's a good model. Subversion just isn't as capable in terms of
> extending this to real sub-branches. Conceptually they are the same.
> In practice, Subversion treats them differently and limits the common
> use.
>
>>> 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.
>>
>
> That's not my proposal. My intent was to show that an automatic
> merge-based model is not a "horror", and that the models (working on a
> side-stream, working on a side-working copy) are conceptually similar
> with similar risks. Designers who do stupid things need to have their
> hands slapped or be burned by their own mistakes until they learn not
> to do that. :-)
>
>> 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
>>
>
> Correct.
>
>> 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.
>
> Yep.
>
> But, I do expect that if user B does rename + merge, and user A does
> "svn update", that this will work properly.
>
> I similarly expect that if user B does rename + merge on a
> side-stream, and merges to the parent (using --reintegrate or
> whatever), and user A does "merge" from the parent stream to their own
> side stream, that this will also work properly.
>
> Both are conceptually similar. The side-working copy is a special
> limited case. In Subversion, emphasis was put on the side-working copy
> case and side-streams seem more of an after thought enhanced later,
> but still incomplete. In GIT, emphasis was put on the side-stream case
> and the working copy *is* a side stream. End result? GIT works as I
> expect. Subversion does not. :-) (And our existing ClearCase solution
> works very well in this scenario as well)
>
> I'm hoping this can be fixed!
Apparently we're on the same page then and just managed to talk past
each other.
-- Brane
Received on 2010-01-07 21:16:25 CET