[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Sticking my nose into the hash controversy
From: |
Joel Crisp |
Subject: |
[Monotone-devel] Sticking my nose into the hash controversy |
Date: |
Fri, 10 Dec 2004 12:10:12 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 |
Hi Guys
Time to unlurk on this one I think.
As a 4+ years experienced Clearcase admin, I don't actually think the
hashes are that bad. The number of times I find myself using Clearcase
UUIDs to specify things is quite large - many of the 'disaster recovery'
options required UUIDs. In the end, it comes down to cut-and-paste, and
having some simple way to find the UUID which is the relevant one -
often from either an error message or one of the ubiquitous ls*
(lsvtree, lsstream, lsbl, etc ) commands which show information about
metadata entities in the UCM(*) project vob. The dot based graphing GUI
(lovely!) seems to be the best option for comprehending archive
structure and providing a source of selecting hashes. (BitKeeper also
provides a similar GUI for changeset dependencies as well as file
version tree). Most of the developers where I work just co/ci using the
SSC integration with JDeveloper, so never care about version tags. For
communication, we tend to use baseline labels, which need to be human
readable and understandable, but can also be human assigned.
(*) UCM is the Clearcase Unified Change Management
projects/streams/components management which adds activities aka
changesets to Clearcase
On a slightly different tack:
We just had a real tarball problem with Clearcase. The problem was that
we have a three stream hierarchy of a global integration stream, then a
number of team integration streams, then a number of developer streams
at either one per developer or one shared between a small group of
developers. (Each stream is backed by a clearcase branch type, which is
a branch specifier shared over multiple files). Developers make changes
grouped into activities (changesets) then deliver them to the team
stream, team leaders ensure stability in the team stream then deliver to
the global stream. One team had a _very_ large number of changes, both
file and lots of directory deltas. When we tried to roll their team
stream up the global one Clearcase barfed. It appears it tried to merge
just the tips of the entities in the team stream onto the global branch,
and was getting confused as the checkedout directories on the
integration stream had the same file linked in lots of places due to all
of the directory structure changes! We ended up having to export, drop
the stream and re-import to fix it - which is a bit of a nuclear option!
One option would be to provide an incremental deliver operation. Not
sure how relevant this is to monotone, but its the first time I've seen
a problem this nasty with Clearcase so I thought it would be worth
highlighting.
To summarize a few points:
1) I don't think hashes and hash notation is a big problem. I have a
slight preference for the separation of the hash into groups of 4 hex
digits.
2) Providing a good source of cut-and-paste for hashes would go a long
way to alleviate the issues around unfriendly identifiers.
3) Developers using an IDE probably don't care anyway.
4) Watch out for merging of very divergent trees
4) Publishing test code coverage figures a la svk would be a good thing ;-)
5) No-one is going to adopt a new SCM system without confidence that it
does the right thing - which means either a large established user base
or very comprehensive test suite and proof that the test suite covers
all of the common cases and most of the uncommon ones.
Hope this is helpful
Cydergoth
- [Monotone-devel] Sticking my nose into the hash controversy,
Joel Crisp <=