[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Subversion vs Clearcase

From: <Chris.Fouts_at_qimonda.com>
Date: 2007-04-30 17:56:23 CEST

>-----Original Message-----
>From: Les Mikesell [mailto:lesmikesell@gmail.com]
>Sent: Monday, April 30, 2007 11:29 AM
>To: Fouts Christopher (QNA RTP PT PREV)
>Cc: users@subversion.tigris.org
>Subject: Re: Subversion vs Clearcase
>
>Chris.Fouts@qimonda.com wrote:
>
>>>> My bad! CC has a config spec that provides a way to pick
>and choose,
>>>> 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
>>>> files
>>>>
>>>> If I remove the second line, I'll ignore the b_R1 branch,
>except for
>>>> 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
>>>> instead.
>>>>
>>>> I can "commit" changes using config specs.
>>> Creating a Complex Tag
>>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.htm
>>> l#svn.branchmerge.tags.mkcomplex
>>>
>>> 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
   //repos/trunk
   //repos/branch/dir1
   //repos/tags/dir2/file1
and do an "svn commit", will the changes go in the
   //repos/trunk
   //repos/branch/dir1
   //repos/tags/dir2/file1
correct?

>
>> - 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
correct?

>
>> - 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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 30 17:56:43 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.