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!
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>
