> -----Original Message-----
> From: Marko Kaening [mailto:mk362_at_mch.osram.de]
> Sent: Friday, April 11, 2008 8:09 AM
> To: users_at_subversion.tigris.org
> Subject: config-specs a la Clearcase
>
> Hi,
>
> how can one as a former Clearcase user and a newbee to subversion
> realize
> clearcase's config specs in subversion?
>
> I understand that Clearcase allows for a whole hierachy of labels to
> define a certain build specification. How can this be reproduced with
> svn?
>
> I am not a Clearcase user myself, just want to convince one to not to
> be
> too afraid of svn... ;)
>
Short answer, don't. (Seven years as a CC admin.) A lot of the
ClearCase paradigms just don't apply to Subversion, and it will increase
the learning curve if you try to cling to the Old Ways.
CC uses lazy branching. SVN doesn't have lazy branching, so there's
little benefit to thinking in terms of config specs. Fortunately, SVN
branching/tagging is nearly instant as compared to CC's slow as molasses
labeling, which makes it very easy to do early branching. No loss
there.
Instead of a config spec, SVN requires that you build the view/baseline
by creating a new directory tree from bits and pieces of other
tags/baselines/modules. Needless to say, you don't want to
create/emulate crazy config specs in SVN. Personally, I have not missed
the lack of flexibility offered by config spec, nor found any need to
assemble crazy Frankenstein baselines/tags.
Stephane already mentioned externals. Additionally, externals and svn
symlinks are not as useful/convenient as CC symlinks.
You don't need a version tree. SVN doesn't have them. More
importantly, version trees were not necessary in CC either (except for
the occasionally really odd merge.) You should be thinking in terms of
baselines and merge tracking, and not focused on an individual file's
version tree.
Directories are 2nd class citizens. In CC, there was little difference
in how a dirs and files were handled. In SVN, you cannot/do_not
directly merge a directory (instead you merge a dir's contents.)
Evil Twins. During merges, a twin is automatically picked. And due to
the way SVN does dir merging (dirs are 2nd class,) that actually works
out pretty well.
CC is file focused. The individual files/dirs were branched. History
was maintained in the individual file/dir objects. In Subversion,
history/branches applies to the *entire* tree. Which is why there is no
need for version trees. That is also why you only need on revision
number for the entire repository instead of having revision numbers per
branch per file/dir object.
'svn log' is your new 'ct find' and 'ct lshis'.
Merge Tracking. SVN won't have it until SVN 1.5. Use svnmerge.py in
the meantime.
Merge Bugs. SVN has several (bidirectional merging for example.) You
will miss CC's ability to merge anything, anywhere, anyhow. OTOH, SVN
merges are one pass, so you don't have to iteratively merge dirs first.
Overall, once svn 1.5 goes live, I think CC is dead meat. (Unless you
really need wink-ins or have a pathological addiction to UCM.)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-11 16:28:56 CEST