>From: Les Mikesell [mailto:email@example.com]
>Sent: Monday, April 30, 2007 11:29 AM
>To: Fouts Christopher (QNA RTP PT PREV)
>Subject: Re: Subversion vs Clearcase
>>>> My bad! CC has a config spec that provides a way to pick
>>>> or "filter" what files can be in a build. What's neat about
>>> it, I can
>>>> mix and match any trunked, tagged, or branched files in the
>>> repos. For
>>>> example, I can
>>>> element foo.c /b_R1/2
>>>> element * /b_R1/latest
>>>> element * /main/latest
>>>> This means, in this order...
>>>> 1. Use v2 of foo.c from the b_R1 branch 2. Use b_R1 branch for the
>>>> rest of the files,
>>>> if the files are on that branch
>>>> 3. Use the /main/latest version of the rest of
>>>> If I remove the second line, I'll ignore the b_R1 branch,
>>>> foo.c /b_R1/2, ON THE FLY.
>>>> I may have added the top line because I found a problem with the
>>>> /b_R1/latest version of foo.c (say v3), so I elected to use v2
>>>> I can "commit" changes using config specs.
>>> Creating a Complex Tag
>>> It is probably more effort to set up with Subversion, but doable.
>> Thanks for the link, but I read it and don't quite follow. Please
>> explain how complex tags can be act like a "confg spec?"
>> - How can I use it to checkout the files I need, and then work with
>> those files?
>Start by checking out the version with the largest portion of
>the files you want - probably the head of the trunk or a
>branch. Then selectively
> update the parts you want to earlier revisions. You could
>do that in a script or batch file if you plan to repeat it,
>but you'd probably be better off branching if you expect to
>re-use this combination.
Can I mix/match trunked/branched/tagged files in my workspace?
For example, will this work?
svn co //repos/trunk myws
svn co //repos/branch/dir1 myws
svn co //repos/tags/dir2/file1 myws
If I then make changes to a file exclusively in the
and do an "svn commit", will the changes go in the
>> - How can I use it to tag (label?) those files?
>You can "svn copy" your current working copy to a tag - or to
>start a new branch. Your working copy does not have to match
>any existing revision when you do this.
Thanks for the reminder! Say I want to tag my above workspace
as R1. I expect the R1 tag to be applied to
the //repos/trunk files
the //repos/branch/dir1 files
the //repos/tags/dir2/file1 file
>> - How can I use it to then commit the changes?
>If you branch, you'd just switch to the branch and work
>normally. What does clearcase do when you commit to something
>you specified as a backrev of a file?
CC uses the config spec I alluded to for ALL transactions!
So if I checkout foo.c, it will checkout the b_R1/2 version
because of my first rule. If I remove that rule, it will
checkout the b_R1/latest (3 in this case) version. BTW, I'll
have to add the
element * CHECKEDOUT
rule to see my checkout out version of a file first.
This flexibility is one feature I really miss. It factors into
CC being an "software configuration manager, or SCM" rather than
just a revision control system. Perforce has a similar feauture,
but NOT as convenient.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Apr 30 17:56:43 2007