path_to_viewstore: each clearcase client has a location on his harddisk where information on the views is kept, this is the viewstore. So normally this is an unc path like \\mycomputer\cc_vws1. (cc_vws1 is our company standard, I don't know if this is a real standard)
path_to_confgspec: it is indeed a file on the network. It contains the rules for selecting the versions of the files you want to see.
hope this clears things up a bit,
regards,
wim
2005/11/30, Emmanuel Venisse <[EMAIL PROTECTED]>:
I'm +1 to add some infos on scm clearcase url but i need some explanations of infos
what is path_to_viewstore? Is it the path to directory where i want to checkout files?
In this case, url is different for each developers, right?
what is path_to_config_spec? Is it a file on the network that describe the view to create?
Emmanuel
Wim Deblauwe a écrit :
> Testing this further, I can't get -stgloc to work, but I can do a
> succesful 'checkout' using -vws. What we need is encoding the location
> of the config spec and the value for the -vws option to get me started
> on implementing this case.
>
> Suggestion:
>
> scm:clearcase:[vws:path_to_viewstore]:[path_to_config_spec]
>
> Example:
> scm:clearcase:vws:\\mycomputer\cc_vws1:\\someserver\ClearCase\myproject\configspec.txt
>
> The checkout command would then create a new snapshot view using the
> given config spec. Note that this config spec will need to include load
> rules and start with element * CHECKOUT, like this:
>
> element * CHECKEDOUT
> element * /main/LATEST
> load \my_test_vob\modules\mymodule
>
> What do you think about that?
>
> If we implement this, it should allow the use of Continuum with
> ClearCase (which is my first goal :))
>
> regards,
>
> Wim
>
> 2005/11/30, Wim Deblauwe <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>:
>
> For information:
> http://fisheye.cenqua.com/viewrep/luntbuild/luntbuild/src/com/luntsys/luntbuild/vcs/BaseClearcaseAdaptor.java?r=1.20
> <http://fisheye.cenqua.com/viewrep/luntbuild/luntbuild/src/com/luntsys/luntbuild/vcs/BaseClearcaseAdaptor.java?r=1.20 >
>
> This is the source code of luntbuild, which has support for
> ClearCase. This is basically what happens:
>
> - They require a property "Clearcase view storage name" or "
> Explicit path for view storage". These options are then used with
> cleartool as -stgloc or -vws respectivaly. I don't know exactly what
> is meant by that, but we probably could use the scm url to provide
> those properties.
> - They also require a config spec in their properties. We could
> encode this in the scm url by making users provide a path to a
> config spec on some (normal, non-clearcase) server. That file can
> then be as complicated as someone would like to make his config
> spec. Note, that for build a release, we can create a config spec
> ourselves because then we need to look at the tag of the release and
> nothing else should be looked at.
>
> - They first create a snapshot view
> - After that, they set the config spec on the snapshot view
>
> Dan, do you know more on the stgloc and vws options?
>
> regards,
>
> Wim
>
>
> 2005/11/28, dan tran <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] >>:
>
> Hi Wim,
>
> We keep our config spec file in a base SCM vob. Our config spec
> file contains
>
> - A bunch of hardly change label ( thirdparty etc)
>
> - UCM label generated by clearcase for each new baseline ( new
> build)
>
>
> For each build, we ask clearcase to do a new baseline which
> generates a bunch new labels for all UCM vobs.
> These info are placed/replaced UCM labels in the config spec
> file. Then the file is labeled. So in order to build/rebuild
> all we need is to
>
> - Creat a SCM to retreive the config spec on a particular label
> - Create new another view with that config spec file.
> - Build.
> - Cleanup by removing the created views
>
>
> We can do the similar to your case by labeling all vobs and
> their files using one label. But this labeling process is
> very slow and long since we have so many vobs and files to
> label. Our current legacy buid is doing exactly that
> and it takes about 2 hours to do the label.
>
> -Dan
>
>
>
>
>
>
> On 11/24/05, *Wim Deblauwe* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> So Dan, you keep your config spec in ClearCase? But to build
> a release, you only need a config spec looking at the label.
> What is more in your config spec? Or am I not understanding
> things completely perhaps?
>
> regards,
>
> Wim
>
> 2005/11/24, Emmanuel Venisse <[EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>>:
>
>
>
> dan tran a écrit :
>>
>>
>> On 11/24/05, *Emmanuel Venisse* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>> <mailto:[EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>>> wrote:
>>
>>
>>
>> dan tran a écrit :
>> > Wim, it looks good to me from base SCM
> configuration perspective.
>> >
>> > I use a mixture of UCM and base SCM
> configurations. I keep the
>> > configspec file
>> > in base SCM. At the time doing the label, I
> update the confispec
>> file
>> > and label that
>> > config spec only.
>> >
>> > At the perform step, i then create a view and
> load that
>> configspec file
>> > base the label
>> >
>> > and the rest is the same as yours.
>> >
>> > so our maven-scm's checkout and label command
> will be
>> different. But we
>> > both use a
>> > config spec file during checkout.
>> >
>> > Emmanuel, how would we go about implementing
> these commands?
>>
>> I don't know, you are our clearcase experts there.
>>
>>
>> I meant from interface perspective since we are going
> to have 2
>> diffirent behaviors of
>> checkout and label.
>>
>> it is going to be 2 diffrent provider plexus
> components with some common
>> commands?
>
> So, checkout and label commands are different for you
> and Wim, right?
> I think we need to keep only one clearcase provider. The
> svn url for clearcase is too simple, we can
> perhaps modify it with type of clearcase configuration,
> and in checkout/label command, you check the
> type of configuration and execute correct clearcase
> commands.
>
> WDYT?
>
>>
>> >
>> > I will be out to town with limited access to
> internet. Will discuss
>> > more when I get back.
>> >
>> > -D
>> >
>> >
>> >
>> >
>> > On 11/23/05, *Wim Deblauwe* <
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>> <mailto: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>
>> > <mailto: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> <mailto:
> [EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>>>>
>> wrote:
>> >
>> > Hi,
>> >
>> > to make release:perform work on ClearCase we
> need to
>> implement the
>> > 'checkout' command for ClearCase (this is
> not what ClearCase user
>> > would call checkout!). As I understand it,
> 'checkout' should
>> copy
>> > the files (with a certain tag) from the
> source control system
>> to a
>> > certain directory and then the build should
> start on those
>> files. So
>> > this is what we need for ClearCase:
>> >
>> > - create a view with a config spec: Since we
> need to look at a
>> > released version and it has been labeled in
> release:prepare
>> if all
>> > is ok, we only need 1 line in the config
> spec, like this
>> >
>> > ELEMENT * RLS_MYPROJECT_V1.0
>> >
>> > - mount the correct vob. Don't know if this
> is really
>> necessairy,
>> > the correct vob should normally already be
> mounted
>> > - cd to the created view
>> > - copy everything to a directory (or run the
> build from the newly
>> > created view?)
>> >
>> > This is the commando's I think we will need
> to call:
>> >
>> > // First create the view
>> > cleartool mkview -tag maven_release_build_view
>> >
> \\MYCOMPUTER\cc_vws1\maven_release_build_view.vws
>> > // Assign the correct config spec
>> > [Create a temp file called configspec.txt
> with the config
>> spec in it]
>> > cleartool setcs -tag
> maven_release_build_view configspec.txt
>> > [Following 2 lines maybe better left out for
> now]
>> > cleartool umount -all
>> > cleartool mount \my_own_vob
>> >
>> > //Do the build here
>> >
>> > //Call the following line after the build -
> If this is not
>> possible
>> > to call after the build, run it at the start
> of the next build
>> > cleartool rmview -force -tag
> maven_release_build_view
>> >
>> >
>> > anybody who agrees or disagrees, please
> comment!
>> >
>> > regards,
>> >
>> > Wim
>> >
>> >
>>
>>
>
>
>
>
>
