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.
I once worked in a company where one of the teams used exactly that
approach and had constantly broken builds because one bit or another was
not properly merged from developer-specific branches to the mainline.
When I asked them why not use a little less granularity in their
branches, e.g., at least per-task or per-bugfix, not per-developer, the
response was that "then the developers would work more slowly because
they'd have to worry about other peoples' commits." QED.
This indicates a broken ClearCase wrapper. ClearCase is useless on its
own as an SCM, and if the wrapper on top does not implement a good
solution, then of course such things as constantly broken builds will
result. It's very easy to write a bad wrapper for ClearCase, and most
companies have done exactly this.
Also, the real reason per-developer is used over per-task or per-bugfix
is due to the overhead of creating branches - both the overhead of their
existence, and the overhead of creating views. Still, of the several
wrappers we have used, two of them *do* implement "per-change"
views/branches.
The response you got was completely bogus. "the developers would work
more slowly because they'd have to worry about other peoples' commits"
is exactly opposite of the truth. Per-task or per-bugfix indicates
shorter lifespan, which results in fewer opportunities to require to
merge with other people's changes. It sounds like they just did things
and thought about things wrong - ClearCase let them. :-)
(You can get the same effect by creating a branch for each developer in
Subversion. You can imagine the horror that integration then becomes.)
It's only a horror because Subversion merging is still immature (mostly
related to renames). It works very well for us under ClearCase, and my
proposal for us to migrate will require that we use per-developer or
per-change branches under Subversion. It also works *great* under GIT,
where each user's workspace really is their own private developer branch
("master"). It works great outside Subversion. I'd like to see it work
great *with* Subversion.
(And just FYI, ClearCase for example /does/ provide a mixed-revision
working copy model.)
This is a matter of interpretation and a matter of wrapper
implementation. ClearCase and Subversion are not alike enough to do a
fair comparison in this regard. Sure, ClearCase *can* be used with
mixed-revision working copy, but this leads to the same sort of broken
build scenarios as Subversion with mixed-revision working copy. A
wrapper solution on top will normally implement a "change" object which
allows per-file revisions to be grouped together. These will be
implemented using labels or attributes, and the config.spec would be
designed to select changes by the labels or attributes in whole or not
at all. The result is that any particular view should only see a set of
exact changes plus local working copy changes, which is exactly the same
as Subversion.
So sure, if you want to look at ClearCase as a useless base, or with
broken wrappers, then yes, it has problems. If you want to look at it
with a mature and capable wrapper, then it can be significantly better
than Subversion today, with Subversion being a big step backwards.
I am looking to see Subversion rise to the point where it is no longer a
step backwards.
Reliable merges, even across renames, would be one huge step here.
Performance improvements would be one huge step here. Ease of working on
sub-branches would be one huge step here.
One area that has concerned me over the life of Subversion, which I've
been glad to see changing and maturing, is the assumption that working
directly on trunk is a good and scaleable solution. Especially in early
Subversion, I saw an attitude of "why would you ever use side branches?"
This was made most clear by Subversion 1.4 and earlier not providing
merge tracking and the merge tracking feature was always low priority.
Some of us have insisted that merge tracking was important from the
beginning. I see it a bit in your comments above. You are saying that
merging is a horror - but appear to not be seeing that every time the
working copy is committed, the working copy itself is a sort of "side
stream", where changes are stored in the working copy, and they are
merged against trunk. With GIT, or a ClearCase model that uses side
streams by default, this concept is generalized where they do not
pretend the working copy is special. The working copy is another stream,
and compared to Subversion, GIT allows multiple commits to be made
before they are merged back to the parent. Subversion is the exact same
here - just it has this odd limit of one only one commit allowed per
working copy "side stream". It's a specialization of the scenario.
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. 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.
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>
