You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm-dev@maven.apache.org by Wim Deblauwe <wi...@gmail.com> on 2005/11/24 08:53:53 UTC
ClearCase 'checkout' implementation
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
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
I am working on it, got approvals from my boss and VP. It is now on legal
department's desk
since I will spend some time during working hours for Maven.
-Dan
On 11/24/05, Emmanuel Venisse <em...@venisse.net> wrote:
>
> Dan,
>
> do you have send your CLA?
>
> Emmanuel
>
> Emmanuel Venisse a écrit :
> >
> >
> > 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 will be out to town with limited access to internet. Will discuss
> >> more when I get back.
> >>
> >> -D
> >>
> >>
> >>
> >>
> >> On 11/23/05, *Wim Deblauwe* <wim.deblauwe@gmail.com
> >> <ma...@gmail.com>> 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
> >>
> >>
> >
> >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
Dan,
do you have send your CLA?
Emmanuel
Emmanuel Venisse a écrit :
>
>
> 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 will be out to town with limited access to internet. Will discuss
>> more when I get back.
>>
>> -D
>>
>>
>>
>>
>> On 11/23/05, *Wim Deblauwe* <wim.deblauwe@gmail.com
>> <ma...@gmail.com>> 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
>>
>>
>
>
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
:)
file an issue and we'll try to add this feature in continuum.
Emmanuel
Wim Deblauwe a écrit :
> True, it would be nice to have dynamic views as well, but this is
> currently the only solution with the way that Continuum works. So, if
> snapshots don't work for you, then I guess you will need to bother
> Emmanuel ;)
>
> regards,
>
> Wim
>
> 2005/12/1, dan tran <dantran@gmail.com <ma...@gmail.com>>:
>
> yup, I never try this before. but teh checkout time will be very
> long for my chase since my legacy system has a lots of dead,
> seldomlyused,larged files.
>
> I rather to stay on the dynamic view rather than snapshot view.
>
> If your system is new and you are carefully organize your soure
> tree, snapshot could be the way to go. but if you are using snapshot
> view
> and the developer using dyanmic view, there will potential finger
> pointing when the build goes wrong.
>
> -Dan
>
>
>
> On 12/1/05, *Wim Deblauwe* <wim.deblauwe@gmail.com
> <ma...@gmail.com>> wrote:
>
> That is not true if you create a snapshot view. It can be in any
> directory. I already implemented and tested this. You can then
> do a 'cleartool update' and that will update the snapshot view.
>
> regards,
>
> Wim
>
> 2005/12/1, dan tran <dantran@gmail.com <ma...@gmail.com>>:
>
> After checkout, clearcase dictates to location of checkout
> directory
>
> on my windows
>
> m:/view-name
>
> on my unix
>
> /view/${view-name}/vobs
>
> So continuum must allow a way to change per build entry to
> the new working direct
> rather ${continuum-workdir}/#
>
> We must stay on clearcase directory inorder to do other
> update/changelog commands
>
> -Dan
>
>
> On 12/1/05, *Emmanuel Venisse* <emmanuel@venisse.net
> <ma...@venisse.net>> wrote:
>
>> I prefer that too, so I filed
>> http://jira.codehaus.org/browse/CONTINUUM-491
> <http://jira.codehaus.org/browse/CONTINUUM-491>. If that
> is easy to fix,
>> could you send me the fix so I continue testing?
>>
>
> I'll fix it today or tomorrow.
>
> Emmanuel
>
>
>
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
True, it would be nice to have dynamic views as well, but this is currently
the only solution with the way that Continuum works. So, if snapshots don't
work for you, then I guess you will need to bother Emmanuel ;)
regards,
Wim
2005/12/1, dan tran <da...@gmail.com>:
>
> yup, I never try this before. but teh checkout time will be very long
> for my chase since my legacy system has a lots of dead, seldomlyused,larged
> files.
>
> I rather to stay on the dynamic view rather than snapshot view.
>
> If your system is new and you are carefully organize your soure tree,
> snapshot could be the way to go. but if you are using snapshot view
> and the developer using dyanmic view, there will potential finger pointing
> when the build goes wrong.
>
> -Dan
>
>
>
> On 12/1/05, Wim Deblauwe <wi...@gmail.com> wrote:
> >
> > That is not true if you create a snapshot view. It can be in any
> > directory. I already implemented and tested this. You can then do a
> > 'cleartool update' and that will update the snapshot view.
> >
> > regards,
> >
> > Wim
> >
> > 2005/12/1, dan tran <da...@gmail.com>:
> > >
> > > After checkout, clearcase dictates to location of checkout directory
> > >
> > > on my windows
> > >
> > > m:/view-name
> > >
> > > on my unix
> > >
> > > /view/${view-name}/vobs
> > >
> > > So continuum must allow a way to change per build entry to the new
> > > working direct
> > > rather ${continuum-workdir}/#
> > >
> > > We must stay on clearcase directory inorder to do other
> > > update/changelog commands
> > >
> > > -Dan
> > >
> > >
> > > On 12/1/05, Emmanuel Venisse <emmanuel@venisse.net > wrote:
> > > >
> > > > > I prefer that too, so I filed
> > > > > http://jira.codehaus.org/browse/CONTINUUM-491 . If that is easy to
> > > > fix,
> > > > > could you send me the fix so I continue testing?
> > > > >
> > > >
> > > > I'll fix it today or tomorrow.
> > > >
> > > > Emmanuel
> > > >
> > > >
> > >
> >
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
yup, I never try this before. but teh checkout time will be very long for
my chase since my legacy system has a lots of dead, seldomlyused,larged
files.
I rather to stay on the dynamic view rather than snapshot view.
If your system is new and you are carefully organize your soure tree,
snapshot could be the way to go. but if you are using snapshot view
and the developer using dyanmic view, there will potential finger pointing
when the build goes wrong.
-Dan
On 12/1/05, Wim Deblauwe <wi...@gmail.com> wrote:
>
> That is not true if you create a snapshot view. It can be in any
> directory. I already implemented and tested this. You can then do a
> 'cleartool update' and that will update the snapshot view.
>
> regards,
>
> Wim
>
> 2005/12/1, dan tran <da...@gmail.com>:
> >
> > After checkout, clearcase dictates to location of checkout directory
> >
> > on my windows
> >
> > m:/view-name
> >
> > on my unix
> >
> > /view/${view-name}/vobs
> >
> > So continuum must allow a way to change per build entry to the new
> > working direct
> > rather ${continuum-workdir}/#
> >
> > We must stay on clearcase directory inorder to do other update/changelog
> > commands
> >
> > -Dan
> >
> >
> > On 12/1/05, Emmanuel Venisse <emmanuel@venisse.net > wrote:
> > >
> > > > I prefer that too, so I filed
> > > > http://jira.codehaus.org/browse/CONTINUUM-491 . If that is easy to
> > > fix,
> > > > could you send me the fix so I continue testing?
> > > >
> > >
> > > I'll fix it today or tomorrow.
> > >
> > > Emmanuel
> > >
> > >
> >
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
That is not true if you create a snapshot view. It can be in any directory.
I already implemented and tested this. You can then do a 'cleartool update'
and that will update the snapshot view.
regards,
Wim
2005/12/1, dan tran <da...@gmail.com>:
>
> After checkout, clearcase dictates to location of checkout directory
>
> on my windows
>
> m:/view-name
>
> on my unix
>
> /view/${view-name}/vobs
>
> So continuum must allow a way to change per build entry to the new working
> direct
> rather ${continuum-workdir}/#
>
> We must stay on clearcase directory inorder to do other update/changelog
> commands
>
> -Dan
>
>
> On 12/1/05, Emmanuel Venisse <em...@venisse.net> wrote:
> >
> > > I prefer that too, so I filed
> > > http://jira.codehaus.org/browse/CONTINUUM-491 . If that is easy to
> > fix,
> > > could you send me the fix so I continue testing?
> > >
> >
> > I'll fix it today or tomorrow.
> >
> > Emmanuel
> >
> >
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
After checkout, clearcase dictates to location of checkout directory
on my windows
m:/view-name
on my unix
/view/${view-name}/vobs
So continuum must allow a way to change per build entry to the new working
direct
rather ${continuum-workdir}/#
We must stay on clearcase directory inorder to do other update/changelog
commands
-Dan
On 12/1/05, Emmanuel Venisse <em...@venisse.net> wrote:
>
> > I prefer that too, so I filed
> > http://jira.codehaus.org/browse/CONTINUUM-491. If that is easy to fix,
> > could you send me the fix so I continue testing?
> >
>
> I'll fix it today or tomorrow.
>
> Emmanuel
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
> I prefer that too, so I filed
> http://jira.codehaus.org/browse/CONTINUUM-491. If that is easy to fix,
> could you send me the fix so I continue testing?
>
I'll fix it today or tomorrow.
Emmanuel
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
2005/12/1, Emmanuel Venisse <em...@venisse.net>:
>
>
>
> Wim Deblauwe a écrit :
> > ah, I haven't done that yet. I'm currently testing with a hardcoded
> value.
> >
> > I managed to checkout to the working directory, but 2 problems:
> >
> > 1) ClearCase does not want to checkout to an already existing directory,
> > so in the checkout command, I first delete the directory to checkout to.
> > It is then re-created by ClearCase. This seems to work fine in my test,
> > so I think this is ok.
>
> if it doesn't want to checkout to an alreasy existing directory, you can
> perhaps test the existence
> of the directory and if it exists, run update command.
I will try if that is possible. I still have to implement the update
command. I tested with a no-op implementation to get me started now.
>
> > 2) pom.xml is not in the root, so the build fails with:
> > Could not find the model file 'C:\Program Files\Apache Software
> > Foundation\continuum-
> 1.0.1\bin\win32\..\..\apps\continuum\working-directory\32\pom.xml'
>
> Why it isn't in root directory? can you checkout mymodule content in
> working directory?
Nope, I haven't found a way. Maybe Dan knows a way?
>
> > That is normal since it is in
> > "...working-directory\32\my_vob\modules\mymodule". ClearCase re-creates
> > the vob structure and everything in between up to where the module
> > actually is. What I have been thinking is creating a temperary snapshot
> > view and then copy everything from that temp location to
> > "working-directory\32". Problem is that I don't know where pom.xml is in
> > that structure, so I don't know how to that.
> > Other solution is that the user updates the build definition to point to
> > the location of the pom, but I tried that and it does not work.
> > Continuum does not seem to take that into account. Is that a known bug?
>
> I think it isn't a good solution to checkout in a temp directory and copy
> all files in the correct
> directory, because it will be slow to do the copy, and updaute will
> perhaps be less esay to do.
>
> I prefer the second solution if you cant checkout mymodule in working
> directory. You're right, it's
> a bug, please, file an issue and i'll fix it before 1.0.2 release.
I prefer that too, so I filed http://jira.codehaus.org/browse/CONTINUUM-491.
If that is easy to fix, could you send me the fix so I continue testing?
regards,
Wim
Emmanuel
> >
> > regards,
> >
> > Wim
> >
> > 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> > <ma...@venisse.net>>:
> >
> > I talk about file parsing in ${user.home}/.scm/
> >
> > Wim Deblauwe a écrit :
> > >
> > >
> > > 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> > <ma...@venisse.net>
> > > <mailto: emmanuel@venisse.net <ma...@venisse.net>>>:
> > >
> > > Remove all maven-scm libs from
> > ${continuum}/apps/continuum/lib and
> > > put in it all new maven-scm libs.
> > >
> > > What do you use for scm file parsing?
> > >
> > > Emmanuel
> > >
> > >
> > > Euh.. just stringtokenizer, like this:
> > >
> > > public class ClearCaseScmProviderRepository
> > > extends ScmProviderRepository
> > > {
> > > private String viewName;
> > > private File configSpec;
> > >
> > > /**
> > > *
> > > * @param url format is [view_name]:[url_to_configspec] or
> > > [view_name]|[url_to_configspec]
> > > */
> > > public ClearCaseScmProviderRepository( String url )
> > > throws ScmRepositoryException
> > > {
> > > try
> > > {
> > > System.out.println( "url = " + url );
> > > parseUrl( url );
> > > }
> > > catch ( MalformedURLException e )
> > > {
> > > throw new ScmRepositoryException( "Illegal URL: " +
> url +
> > > "(" + e.getMessage() + ")" );
> > > }
> > > catch ( URISyntaxException e )
> > > {
> > > throw new ScmRepositoryException( "Illegal URL: " +
> url +
> > > "(" + e.getMessage() + ")" );
> > > }
> > > catch ( UnknownHostException e )
> > > {
> > > throw new ScmRepositoryException( "Illegal URL: " +
> url +
> > > "(" + e.getMessage() + ")" );
> > > }
> > > }
> > >
> > > private void parseUrl( String url )
> > > throws MalformedURLException, URISyntaxException,
> > > UnknownHostException
> > > {
> > > if( url.indexOf( '|' ) != -1 )
> > > {
> > > StringTokenizer tokenizer = new StringTokenizer( url,
> > "|" );
> > > fillInProperties( tokenizer );
> > > }
> > > else
> > > {
> > > StringTokenizer tokenizer = new StringTokenizer( url,
> > ":" );
> > > fillInProperties( tokenizer );
> > > }
> > > }
> > >
> > > private void fillInProperties( StringTokenizer tokenizer )
> > > throws UnknownHostException, URISyntaxException,
> > > MalformedURLException
> > > {
> > > if( tokenizer.countTokens() == 1 )
> > > {
> > > //No view name was given
> > > viewName = getDefaultViewName();
> > > String spec = tokenizer.nextToken();
> > > System.out.println( "spec = " + spec );
> > > configSpec = createConfigSpecFile( spec );
> > > }
> > > else
> > > {
> > > viewName = tokenizer.nextToken();
> > > System.out.println( "viewName = " + viewName );
> > > String pathname = tokenizer.nextToken();
> > > System.out.println( "pathname = " + pathname );
> > > configSpec = createConfigSpecFile( pathname );
> > > }
> > > }
> > >
> > > private File createConfigSpecFile( String spec )
> > > throws URISyntaxException, MalformedURLException
> > > {
> > > File result;
> > > if( spec.indexOf( ':' ) == -1 )
> > > {
> > > result = new File( spec );
> > > }
> > > else
> > > {
> > > result = new File( new URL( spec ).toURI() );
> > > }
> > > return result;
> > > }
> > >
> > > /**
> > > * Default: ${hostname}-{ user.name <http://user.name>
> > <http://user.name>}-${artifactId}
> > > * @return
> > > */
> > > private String getDefaultViewName()
> > > throws UnknownHostException
> > > {
> > > String username = System.getProperty( "user.name
> > <http://user.name>
> > > <http://user.name>", "nouser" );
> > > String hostname = getHostName();
> > > return username + "-" + hostname + "-maven";
> > > }
> > >
> > > private String getHostName()
> > > throws UnknownHostException
> > > {
> > > return InetAddress.getLocalHost().getHostName();
> > > }
> > >
> > > public String getViewName()
> > > {
> > > return viewName;
> > > }
> > >
> > > public File getConfigSpec()
> > > {
> > > return configSpec;
> > > }
> > > }
> > >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
Wim Deblauwe a écrit :
> ah, I haven't done that yet. I'm currently testing with a hardcoded value.
>
> I managed to checkout to the working directory, but 2 problems:
>
> 1) ClearCase does not want to checkout to an already existing directory,
> so in the checkout command, I first delete the directory to checkout to.
> It is then re-created by ClearCase. This seems to work fine in my test,
> so I think this is ok.
if it doesn't want to checkout to an alreasy existing directory, you can perhaps test the existence
of the directory and if it exists, run update command.
>
> 2) pom.xml is not in the root, so the build fails with:
> Could not find the model file 'C:\Program Files\Apache Software
> Foundation\continuum-1.0.1\bin\win32\..\..\apps\continuum\working-directory\32\pom.xml'
Why it isn't in root directory? can you checkout mymodule content in working directory?
>
> That is normal since it is in
> "...working-directory\32\my_vob\modules\mymodule". ClearCase re-creates
> the vob structure and everything in between up to where the module
> actually is. What I have been thinking is creating a temperary snapshot
> view and then copy everything from that temp location to
> "working-directory\32". Problem is that I don't know where pom.xml is in
> that structure, so I don't know how to that.
> Other solution is that the user updates the build definition to point to
> the location of the pom, but I tried that and it does not work.
> Continuum does not seem to take that into account. Is that a known bug?
I think it isn't a good solution to checkout in a temp directory and copy all files in the correct
directory, because it will be slow to do the copy, and updaute will perhaps be less esay to do.
I prefer the second solution if you cant checkout mymodule in working directory. You're right, it's
a bug, please, file an issue and i'll fix it before 1.0.2 release.
Emmanuel
>
> regards,
>
> Wim
>
> 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> <ma...@venisse.net>>:
>
> I talk about file parsing in ${user.home}/.scm/
>
> Wim Deblauwe a écrit :
> >
> >
> > 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> <ma...@venisse.net>
> > <mailto: emmanuel@venisse.net <ma...@venisse.net>>>:
> >
> > Remove all maven-scm libs from
> ${continuum}/apps/continuum/lib and
> > put in it all new maven-scm libs.
> >
> > What do you use for scm file parsing?
> >
> > Emmanuel
> >
> >
> > Euh.. just stringtokenizer, like this:
> >
> > public class ClearCaseScmProviderRepository
> > extends ScmProviderRepository
> > {
> > private String viewName;
> > private File configSpec;
> >
> > /**
> > *
> > * @param url format is [view_name]:[url_to_configspec] or
> > [view_name]|[url_to_configspec]
> > */
> > public ClearCaseScmProviderRepository( String url )
> > throws ScmRepositoryException
> > {
> > try
> > {
> > System.out.println( "url = " + url );
> > parseUrl( url );
> > }
> > catch ( MalformedURLException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > catch ( URISyntaxException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > catch ( UnknownHostException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > }
> >
> > private void parseUrl( String url )
> > throws MalformedURLException, URISyntaxException,
> > UnknownHostException
> > {
> > if( url.indexOf( '|' ) != -1 )
> > {
> > StringTokenizer tokenizer = new StringTokenizer( url,
> "|" );
> > fillInProperties( tokenizer );
> > }
> > else
> > {
> > StringTokenizer tokenizer = new StringTokenizer( url,
> ":" );
> > fillInProperties( tokenizer );
> > }
> > }
> >
> > private void fillInProperties( StringTokenizer tokenizer )
> > throws UnknownHostException, URISyntaxException,
> > MalformedURLException
> > {
> > if( tokenizer.countTokens() == 1 )
> > {
> > //No view name was given
> > viewName = getDefaultViewName();
> > String spec = tokenizer.nextToken();
> > System.out.println( "spec = " + spec );
> > configSpec = createConfigSpecFile( spec );
> > }
> > else
> > {
> > viewName = tokenizer.nextToken();
> > System.out.println( "viewName = " + viewName );
> > String pathname = tokenizer.nextToken();
> > System.out.println( "pathname = " + pathname );
> > configSpec = createConfigSpecFile( pathname );
> > }
> > }
> >
> > private File createConfigSpecFile( String spec )
> > throws URISyntaxException, MalformedURLException
> > {
> > File result;
> > if( spec.indexOf( ':' ) == -1 )
> > {
> > result = new File( spec );
> > }
> > else
> > {
> > result = new File( new URL( spec ).toURI() );
> > }
> > return result;
> > }
> >
> > /**
> > * Default: ${hostname}-{ user.name <http://user.name>
> <http://user.name>}-${artifactId}
> > * @return
> > */
> > private String getDefaultViewName()
> > throws UnknownHostException
> > {
> > String username = System.getProperty( "user.name
> <http://user.name>
> > <http://user.name>", "nouser" );
> > String hostname = getHostName();
> > return username + "-" + hostname + "-maven";
> > }
> >
> > private String getHostName()
> > throws UnknownHostException
> > {
> > return InetAddress.getLocalHost().getHostName();
> > }
> >
> > public String getViewName()
> > {
> > return viewName;
> > }
> >
> > public File getConfigSpec()
> > {
> > return configSpec;
> > }
> > }
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
ah, I haven't done that yet. I'm currently testing with a hardcoded value.
I managed to checkout to the working directory, but 2 problems:
1) ClearCase does not want to checkout to an already existing directory, so
in the checkout command, I first delete the directory to checkout to. It is
then re-created by ClearCase. This seems to work fine in my test, so I think
this is ok.
2) pom.xml is not in the root, so the build fails with:
Could not find the model file 'C:\Program Files\Apache Software
Foundation\continuum-
1.0.1\bin\win32\..\..\apps\continuum\working-directory\32\pom.xml'
That is normal since it is in
"...working-directory\32\my_vob\modules\mymodule". ClearCase re-creates the
vob structure and everything in between up to where the module actually is.
What I have been thinking is creating a temperary snapshot view and then
copy everything from that temp location to "working-directory\32". Problem
is that I don't know where pom.xml is in that structure, so I don't know how
to that.
Other solution is that the user updates the build definition to point to the
location of the pom, but I tried that and it does not work. Continuum does
not seem to take that into account. Is that a known bug?
regards,
Wim
2005/12/1, Emmanuel Venisse <em...@venisse.net>:
>
> I talk about file parsing in ${user.home}/.scm/
>
> Wim Deblauwe a écrit :
> >
> >
> > 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> > <ma...@venisse.net>>:
> >
> > Remove all maven-scm libs from ${continuum}/apps/continuum/lib and
> > put in it all new maven-scm libs.
> >
> > What do you use for scm file parsing?
> >
> > Emmanuel
> >
> >
> > Euh.. just stringtokenizer, like this:
> >
> > public class ClearCaseScmProviderRepository
> > extends ScmProviderRepository
> > {
> > private String viewName;
> > private File configSpec;
> >
> > /**
> > *
> > * @param url format is [view_name]:[url_to_configspec] or
> > [view_name]|[url_to_configspec]
> > */
> > public ClearCaseScmProviderRepository( String url )
> > throws ScmRepositoryException
> > {
> > try
> > {
> > System.out.println( "url = " + url );
> > parseUrl( url );
> > }
> > catch ( MalformedURLException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > catch ( URISyntaxException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > catch ( UnknownHostException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > }
> >
> > private void parseUrl( String url )
> > throws MalformedURLException, URISyntaxException,
> > UnknownHostException
> > {
> > if( url.indexOf( '|' ) != -1 )
> > {
> > StringTokenizer tokenizer = new StringTokenizer( url, "|" );
> > fillInProperties( tokenizer );
> > }
> > else
> > {
> > StringTokenizer tokenizer = new StringTokenizer( url, ":" );
> > fillInProperties( tokenizer );
> > }
> > }
> >
> > private void fillInProperties( StringTokenizer tokenizer )
> > throws UnknownHostException, URISyntaxException,
> > MalformedURLException
> > {
> > if( tokenizer.countTokens() == 1 )
> > {
> > //No view name was given
> > viewName = getDefaultViewName();
> > String spec = tokenizer.nextToken();
> > System.out.println( "spec = " + spec );
> > configSpec = createConfigSpecFile( spec );
> > }
> > else
> > {
> > viewName = tokenizer.nextToken();
> > System.out.println( "viewName = " + viewName );
> > String pathname = tokenizer.nextToken();
> > System.out.println( "pathname = " + pathname );
> > configSpec = createConfigSpecFile( pathname );
> > }
> > }
> >
> > private File createConfigSpecFile( String spec )
> > throws URISyntaxException, MalformedURLException
> > {
> > File result;
> > if( spec.indexOf( ':' ) == -1 )
> > {
> > result = new File( spec );
> > }
> > else
> > {
> > result = new File( new URL( spec ).toURI() );
> > }
> > return result;
> > }
> >
> > /**
> > * Default: ${hostname}-{user.name <http://user.name>}-${artifactId}
> > * @return
> > */
> > private String getDefaultViewName()
> > throws UnknownHostException
> > {
> > String username = System.getProperty( "user.name
> > <http://user.name>", "nouser" );
> > String hostname = getHostName();
> > return username + "-" + hostname + "-maven";
> > }
> >
> > private String getHostName()
> > throws UnknownHostException
> > {
> > return InetAddress.getLocalHost().getHostName();
> > }
> >
> > public String getViewName()
> > {
> > return viewName;
> > }
> >
> > public File getConfigSpec()
> > {
> > return configSpec;
> > }
> > }
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
I talk about file parsing in ${user.home}/.scm/
Wim Deblauwe a écrit :
>
>
> 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> <ma...@venisse.net>>:
>
> Remove all maven-scm libs from ${continuum}/apps/continuum/lib and
> put in it all new maven-scm libs.
>
> What do you use for scm file parsing?
>
> Emmanuel
>
>
> Euh.. just stringtokenizer, like this:
>
> public class ClearCaseScmProviderRepository
> extends ScmProviderRepository
> {
> private String viewName;
> private File configSpec;
>
> /**
> *
> * @param url format is [view_name]:[url_to_configspec] or
> [view_name]|[url_to_configspec]
> */
> public ClearCaseScmProviderRepository( String url )
> throws ScmRepositoryException
> {
> try
> {
> System.out.println( "url = " + url );
> parseUrl( url );
> }
> catch ( MalformedURLException e )
> {
> throw new ScmRepositoryException( "Illegal URL: " + url +
> "(" + e.getMessage() + ")" );
> }
> catch ( URISyntaxException e )
> {
> throw new ScmRepositoryException( "Illegal URL: " + url +
> "(" + e.getMessage() + ")" );
> }
> catch ( UnknownHostException e )
> {
> throw new ScmRepositoryException( "Illegal URL: " + url +
> "(" + e.getMessage() + ")" );
> }
> }
>
> private void parseUrl( String url )
> throws MalformedURLException, URISyntaxException,
> UnknownHostException
> {
> if( url.indexOf( '|' ) != -1 )
> {
> StringTokenizer tokenizer = new StringTokenizer( url, "|" );
> fillInProperties( tokenizer );
> }
> else
> {
> StringTokenizer tokenizer = new StringTokenizer( url, ":" );
> fillInProperties( tokenizer );
> }
> }
>
> private void fillInProperties( StringTokenizer tokenizer )
> throws UnknownHostException, URISyntaxException,
> MalformedURLException
> {
> if( tokenizer.countTokens() == 1 )
> {
> //No view name was given
> viewName = getDefaultViewName();
> String spec = tokenizer.nextToken();
> System.out.println( "spec = " + spec );
> configSpec = createConfigSpecFile( spec );
> }
> else
> {
> viewName = tokenizer.nextToken();
> System.out.println( "viewName = " + viewName );
> String pathname = tokenizer.nextToken();
> System.out.println( "pathname = " + pathname );
> configSpec = createConfigSpecFile( pathname );
> }
> }
>
> private File createConfigSpecFile( String spec )
> throws URISyntaxException, MalformedURLException
> {
> File result;
> if( spec.indexOf( ':' ) == -1 )
> {
> result = new File( spec );
> }
> else
> {
> result = new File( new URL( spec ).toURI() );
> }
> return result;
> }
>
> /**
> * Default: ${hostname}-{user.name <http://user.name>}-${artifactId}
> * @return
> */
> private String getDefaultViewName()
> throws UnknownHostException
> {
> String username = System.getProperty( "user.name
> <http://user.name>", "nouser" );
> String hostname = getHostName();
> return username + "-" + hostname + "-maven";
> }
>
> private String getHostName()
> throws UnknownHostException
> {
> return InetAddress.getLocalHost().getHostName();
> }
>
> public String getViewName()
> {
> return viewName;
> }
>
> public File getConfigSpec()
> {
> return configSpec;
> }
> }
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
2005/12/1, Emmanuel Venisse <em...@venisse.net>:
>
> Remove all maven-scm libs from ${continuum}/apps/continuum/lib and put in
> it all new maven-scm libs.
>
> What do you use for scm file parsing?
>
> Emmanuel
>
Euh.. just stringtokenizer, like this:
public class ClearCaseScmProviderRepository
extends ScmProviderRepository
{
private String viewName;
private File configSpec;
/**
*
* @param url format is [view_name]:[url_to_configspec] or
[view_name]|[url_to_configspec]
*/
public ClearCaseScmProviderRepository( String url )
throws ScmRepositoryException
{
try
{
System.out.println( "url = " + url );
parseUrl( url );
}
catch ( MalformedURLException e )
{
throw new ScmRepositoryException( "Illegal URL: " + url + "(" +
e.getMessage() + ")" );
}
catch ( URISyntaxException e )
{
throw new ScmRepositoryException( "Illegal URL: " + url + "(" +
e.getMessage() + ")" );
}
catch ( UnknownHostException e )
{
throw new ScmRepositoryException( "Illegal URL: " + url + "(" +
e.getMessage() + ")" );
}
}
private void parseUrl( String url )
throws MalformedURLException, URISyntaxException,
UnknownHostException
{
if( url.indexOf( '|' ) != -1 )
{
StringTokenizer tokenizer = new StringTokenizer( url, "|" );
fillInProperties( tokenizer );
}
else
{
StringTokenizer tokenizer = new StringTokenizer( url, ":" );
fillInProperties( tokenizer );
}
}
private void fillInProperties( StringTokenizer tokenizer )
throws UnknownHostException, URISyntaxException,
MalformedURLException
{
if( tokenizer.countTokens() == 1 )
{
//No view name was given
viewName = getDefaultViewName();
String spec = tokenizer.nextToken();
System.out.println( "spec = " + spec );
configSpec = createConfigSpecFile( spec );
}
else
{
viewName = tokenizer.nextToken();
System.out.println( "viewName = " + viewName );
String pathname = tokenizer.nextToken();
System.out.println( "pathname = " + pathname );
configSpec = createConfigSpecFile( pathname );
}
}
private File createConfigSpecFile( String spec )
throws URISyntaxException, MalformedURLException
{
File result;
if( spec.indexOf( ':' ) == -1 )
{
result = new File( spec );
}
else
{
result = new File( new URL( spec ).toURI() );
}
return result;
}
/**
* Default: ${hostname}-{user.name}-${artifactId}
* @return
*/
private String getDefaultViewName()
throws UnknownHostException
{
String username = System.getProperty( "user.name", "nouser" );
String hostname = getHostName();
return username + "-" + hostname + "-maven";
}
private String getHostName()
throws UnknownHostException
{
return InetAddress.getLocalHost().getHostName();
}
public String getViewName()
{
return viewName;
}
public File getConfigSpec()
{
return configSpec;
}
}
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
Remove all maven-scm libs from ${continuum}/apps/continuum/lib and put in it all new maven-scm libs.
What do you use for scm file parsing?
Emmanuel
Wim Deblauwe a écrit :
> ok, I'm implementing all of this. We'll see how it goes. But I need to
> test this ofcourse. How can I use/update Continuum 1.0.1 to test with
> ClearCase?
>
> regards,
>
> Wim
>
> 2005/12/1, Wim Deblauwe < wim.deblauwe@gmail.com
> <ma...@gmail.com>>:
>
> I agree 100% that we will need proper help. I'm a firm believer that
> if a feature is not documented, it does not exist, because no-one
> will know how to use it.
>
> 2005/12/1, Emmanuel Venisse < emmanuel@venisse.net
> <ma...@venisse.net>>:
>
> I'm agree for a new file, but not in ${ user.home}/.m2 because
> maven-scm and m2 are independant.
> You can use ${user.home}/.scm
>
> When it will be implemented, you'll should update the site
> content and explain how maven-scm works
> with clearcase.
>
> Emmanuel
>
> Wim Deblauwe a écrit :
>> I like that. I agree that we should not (ab)use settings.xml for a
>> custom plugin. If we now agree on the format for the file, we
> are set to
>> go :)
>>
>> Let me whip up an example:
>>
>> <clearcase>
>> <viewstore>\\${hostname}\viewstore</viewstore>
>> </clearcase>
>>
>> If we could pull this off, then probably all users in a
> certain company
>> could use the same file. If we can't figure out the hostname,
> then we
>> will need to have a different file for each user.
>>
>> regards,
>>
>> Wim
>>
>> 2005/11/30, dan tran < dantran@gmail.com
> <ma...@gmail.com> <mailto:dantran@gmail.com
> <ma...@gmail.com>>>:
>>
>> It makes me feel better. Perhaps we can get clearcase
> provider to
>> look for a property file under ${ user.home}.
>> Shall it be ${user.home}/.m2/clearcase-settings.xml ?
>>
>> -D
>>
>>
>>
>> On 11/30/05, *Jeff Jensen* <
> jeffjensen@upstairstechnology.com
> <ma...@upstairstechnology.com>
>> <mailto:jeffjensen@upstairstechnology.com
> <ma...@upstairstechnology.com>>> wrote:
>>
>> Quoting Emmanuel Venisse < emmanuel@venisse.net
> <ma...@venisse.net>
>> <mailto:emmanuel@venisse.net
> <ma...@venisse.net>>>:
>>
>> >
>> >
>> > Wim Deblauwe a écrit :
>> > >
>> > >
>> > > 2005/11/30, dan tran <dantran@gmail.com
> <ma...@gmail.com>
>> <mailto: dantran@gmail.com <ma...@gmail.com>>
> <mailto: dantran@gmail.com <ma...@gmail.com>
>> <mailto:dantran@gmail.com <ma...@gmail.com>>>>:
>> > >
>> > >
>> > >
>> > > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> <ma...@gmail.com>
>> <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>>
>> > > <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>
>> <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>>> wrote:
>> > >
>> > > Good suggestions there Dan! It is indeed platform
>> dependant and
>> > > following the maven 2 way, we should be able to put
>> those things
>> > > in the settings.xml. Is that possible? That way,
>> it's not needed
>> > > anymore in the scm url.
>> > >
>> > >
>> > > Unfortunatly we dont have access to setting.xml from
>> maven-scm.
>> > > Therefore we may endup
>> > > implementing access to setting.xml in both
>> maven-scm-plugin and
>> > > maven-release-plugin.
>> > > We may be able to replace release:perform step with
>> scm:bootstrap.
>> > > So only one place has
>> > > the setting info. However I dont know if settings.xml
>> has room for
>> > > this type of user preferences.
>> > >
>> > >
>> > > Should we mail Brett or someone else about this?
>> >
>> > I don't want to access to settings.xml in maven-scm.
>> setting.xml in a maven2
>> > file and maven-scm can
>> > be use without it, so i think it isn't a good idea to create a
>> maven2 file
>> > for an independant tool.
>> > If clearcase infos can't be specified in scm url, i think it's
>> better to use
>> > system property or we
>> > can read an environment variable like CLEARCASE_VIEW_STORE_PATH
>>
>> My .02: I would want all config info in the config
> files. Not
>> env vars, etc.
>> For homogenous environments, each user can get the info
> from the
>> source
>> controlled config files.
>>
>>
>> > > Does Continuum 'checkout' the code, builds and then removes
>> the working
>> > > directory again? Or does the working directory remain and is
>> there some
>> > > kind of update command that should happen?
>> >
>> > We don't remove working directory actually, and we update this
>> directory in
>> > each build. In future
>> > version, continuum users will can choose to update or checkout
>> sources. For
>> > example update for
>> > hourly builds and full checkout for nightly builds
>>
>> Just FYI - Perforce requires a "remove from workspace"
> to remove
>> all the files
>> locally, as it tracks all file versions it gives each
>> user. This is why
>> updates are so blazingly faster than its
> competition. One can
>> manually delete
>> the files, but Perforce will still think you have them. A
>> Perforce user does
>> the same action for a "update get latest" and a "full get
>> latest": just a
>> sync/get latest. Removing all the files and then doing
> a get
>> latest will have
>> the same end result, just take a lot longer!
>>
>>
>>
>
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
ok, I'm implementing all of this. We'll see how it goes. But I need to test
this ofcourse. How can I use/update Continuum 1.0.1 to test with ClearCase?
regards,
Wim
2005/12/1, Wim Deblauwe <wi...@gmail.com>:
>
> I agree 100% that we will need proper help. I'm a firm believer that if a
> feature is not documented, it does not exist, because no-one will know how
> to use it.
>
> 2005/12/1, Emmanuel Venisse < emmanuel@venisse.net>:
> >
> > I'm agree for a new file, but not in ${ user.home}/.m2 because maven-scm
> > and m2 are independant.
> > You can use ${user.home}/.scm
> >
> > When it will be implemented, you'll should update the site content and
> > explain how maven-scm works
> > with clearcase.
> >
> > Emmanuel
> >
> > Wim Deblauwe a écrit :
> > > I like that. I agree that we should not (ab)use settings.xml for a
> > > custom plugin. If we now agree on the format for the file, we are set
> > to
> > > go :)
> > >
> > > Let me whip up an example:
> > >
> > > <clearcase>
> > > <viewstore>\\${hostname}\viewstore</viewstore>
> > > </clearcase>
> > >
> > > If we could pull this off, then probably all users in a certain
> > company
> > > could use the same file. If we can't figure out the hostname, then we
> > > will need to have a different file for each user.
> > >
> > > regards,
> > >
> > > Wim
> > >
> > > 2005/11/30, dan tran < dantran@gmail.com <ma...@gmail.com>>:
> > >
> > > It makes me feel better. Perhaps we can get clearcase provider to
> > > look for a property file under ${ user.home}.
> > > Shall it be ${user.home}/.m2/clearcase-settings.xml ?
> > >
> > > -D
> > >
> > >
> > >
> > > On 11/30/05, *Jeff Jensen* <jeffjensen@upstairstechnology.com
> > > <ma...@upstairstechnology.com>> wrote:
> > >
> > > Quoting Emmanuel Venisse < emmanuel@venisse.net
> > > <ma...@venisse.net>>:
> > >
> > >>
> > >>
> > >> Wim Deblauwe a écrit :
> > >> >
> > >> >
> > >> > 2005/11/30, dan tran <dantran@gmail.com
> > > <ma...@gmail.com> <mailto: dantran@gmail.com
> > > <ma...@gmail.com>>>:
> > >> >
> > >> >
> > >> >
> > >> > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> > > <ma...@gmail.com>
> > >> > <mailto: wim.deblauwe@gmail.com
> > > <ma...@gmail.com>>> wrote:
> > >> >
> > >> > Good suggestions there Dan! It is indeed platform
> > > dependant and
> > >> > following the maven 2 way, we should be able to put
> > > those things
> > >> > in the settings.xml. Is that possible? That way,
> > > it's not needed
> > >> > anymore in the scm url.
> > >> >
> > >> >
> > >> > Unfortunatly we dont have access to setting.xml from
> > > maven-scm.
> > >> > Therefore we may endup
> > >> > implementing access to setting.xml in both
> > > maven-scm-plugin and
> > >> > maven-release-plugin.
> > >> > We may be able to replace release:perform step with
> > > scm:bootstrap.
> > >> > So only one place has
> > >> > the setting info. However I dont know if settings.xml
> > > has room for
> > >> > this type of user preferences.
> > >> >
> > >> >
> > >> > Should we mail Brett or someone else about this?
> > >>
> > >> I don't want to access to settings.xml in maven-scm.
> > > setting.xml in a maven2
> > >> file and maven-scm can
> > >> be use without it, so i think it isn't a good idea to create a
> > > maven2 file
> > >> for an independant tool.
> > >> If clearcase infos can't be specified in scm url, i think it's
> > > better to use
> > >> system property or we
> > >> can read an environment variable like CLEARCASE_VIEW_STORE_PATH
> > >
> > > My .02: I would want all config info in the config files. Not
> >
> > > env vars, etc.
> > > For homogenous environments, each user can get the info from
> > the
> > > source
> > > controlled config files.
> > >
> > >
> > >> > Does Continuum 'checkout' the code, builds and then removes
> > > the working
> > >> > directory again? Or does the working directory remain and is
> > > there some
> > >> > kind of update command that should happen?
> > >>
> > >> We don't remove working directory actually, and we update this
> > > directory in
> > >> each build. In future
> > >> version, continuum users will can choose to update or checkout
> > > sources. For
> > >> example update for
> > >> hourly builds and full checkout for nightly builds
> > >
> > > Just FYI - Perforce requires a "remove from workspace" to
> > remove
> > > all the files
> > > locally, as it tracks all file versions it gives each
> > > user. This is why
> > > updates are so blazingly faster than its competition. One can
> > > manually delete
> > > the files, but Perforce will still think you have them. A
> > > Perforce user does
> > > the same action for a "update get latest" and a "full get
> > > latest": just a
> > > sync/get latest. Removing all the files and then doing a get
> > > latest will have
> > > the same end result, just take a lot longer!
> > >
> > >
> > >
> >
> >
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
I agree 100% that we will need proper help. I'm a firm believer that if a
feature is not documented, it does not exist, because no-one will know how
to use it.
2005/12/1, Emmanuel Venisse <em...@venisse.net>:
>
> I'm agree for a new file, but not in ${user.home}/.m2 because maven-scm
> and m2 are independant.
> You can use ${user.home}/.scm
>
> When it will be implemented, you'll should update the site content and
> explain how maven-scm works
> with clearcase.
>
> Emmanuel
>
> Wim Deblauwe a écrit :
> > I like that. I agree that we should not (ab)use settings.xml for a
> > custom plugin. If we now agree on the format for the file, we are set to
> > go :)
> >
> > Let me whip up an example:
> >
> > <clearcase>
> > <viewstore>\\${hostname}\viewstore</viewstore>
> > </clearcase>
> >
> > If we could pull this off, then probably all users in a certain company
> > could use the same file. If we can't figure out the hostname, then we
> > will need to have a different file for each user.
> >
> > regards,
> >
> > Wim
> >
> > 2005/11/30, dan tran <dantran@gmail.com <ma...@gmail.com>>:
> >
> > It makes me feel better. Perhaps we can get clearcase provider to
> > look for a property file under ${user.home}.
> > Shall it be ${user.home}/.m2/clearcase-settings.xml ?
> >
> > -D
> >
> >
> >
> > On 11/30/05, *Jeff Jensen* <jeffjensen@upstairstechnology.com
> > <ma...@upstairstechnology.com>> wrote:
> >
> > Quoting Emmanuel Venisse < emmanuel@venisse.net
> > <ma...@venisse.net>>:
> >
> >>
> >>
> >> Wim Deblauwe a écrit :
> >> >
> >> >
> >> > 2005/11/30, dan tran <dantran@gmail.com
> > <ma...@gmail.com> <mailto:dantran@gmail.com
> > <ma...@gmail.com>>>:
> >> >
> >> >
> >> >
> >> > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> > <ma...@gmail.com>
> >> > <mailto: wim.deblauwe@gmail.com
> > <ma...@gmail.com>>> wrote:
> >> >
> >> > Good suggestions there Dan! It is indeed platform
> > dependant and
> >> > following the maven 2 way, we should be able to put
> > those things
> >> > in the settings.xml. Is that possible? That way,
> > it's not needed
> >> > anymore in the scm url.
> >> >
> >> >
> >> > Unfortunatly we dont have access to setting.xml from
> > maven-scm.
> >> > Therefore we may endup
> >> > implementing access to setting.xml in both
> > maven-scm-plugin and
> >> > maven-release-plugin.
> >> > We may be able to replace release:perform step with
> > scm:bootstrap.
> >> > So only one place has
> >> > the setting info. However I dont know if settings.xml
> > has room for
> >> > this type of user preferences.
> >> >
> >> >
> >> > Should we mail Brett or someone else about this?
> >>
> >> I don't want to access to settings.xml in maven-scm.
> > setting.xml in a maven2
> >> file and maven-scm can
> >> be use without it, so i think it isn't a good idea to create a
> > maven2 file
> >> for an independant tool.
> >> If clearcase infos can't be specified in scm url, i think it's
> > better to use
> >> system property or we
> >> can read an environment variable like CLEARCASE_VIEW_STORE_PATH
> >
> > My .02: I would want all config info in the config files. Not
> > env vars, etc.
> > For homogenous environments, each user can get the info from the
> > source
> > controlled config files.
> >
> >
> >> > Does Continuum 'checkout' the code, builds and then removes
> > the working
> >> > directory again? Or does the working directory remain and is
> > there some
> >> > kind of update command that should happen?
> >>
> >> We don't remove working directory actually, and we update this
> > directory in
> >> each build. In future
> >> version, continuum users will can choose to update or checkout
> > sources. For
> >> example update for
> >> hourly builds and full checkout for nightly builds
> >
> > Just FYI - Perforce requires a "remove from workspace" to remove
> > all the files
> > locally, as it tracks all file versions it gives each
> > user. This is why
> > updates are so blazingly faster than its competition. One can
> > manually delete
> > the files, but Perforce will still think you have them. A
> > Perforce user does
> > the same action for a "update get latest" and a "full get
> > latest": just a
> > sync/get latest. Removing all the files and then doing a get
> > latest will have
> > the same end result, just take a lot longer!
> >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
I'm agree for a new file, but not in ${user.home}/.m2 because maven-scm and m2 are independant.
You can use ${user.home}/.scm
When it will be implemented, you'll should update the site content and explain how maven-scm works
with clearcase.
Emmanuel
Wim Deblauwe a écrit :
> I like that. I agree that we should not (ab)use settings.xml for a
> custom plugin. If we now agree on the format for the file, we are set to
> go :)
>
> Let me whip up an example:
>
> <clearcase>
> <viewstore>\\${hostname}\viewstore</viewstore>
> </clearcase>
>
> If we could pull this off, then probably all users in a certain company
> could use the same file. If we can't figure out the hostname, then we
> will need to have a different file for each user.
>
> regards,
>
> Wim
>
> 2005/11/30, dan tran <dantran@gmail.com <ma...@gmail.com>>:
>
> It makes me feel better. Perhaps we can get clearcase provider to
> look for a property file under ${user.home}.
> Shall it be ${user.home}/.m2/clearcase-settings.xml ?
>
> -D
>
>
>
> On 11/30/05, *Jeff Jensen* <jeffjensen@upstairstechnology.com
> <ma...@upstairstechnology.com>> wrote:
>
> Quoting Emmanuel Venisse < emmanuel@venisse.net
> <ma...@venisse.net>>:
>
>>
>>
>> Wim Deblauwe a écrit :
>> >
>> >
>> > 2005/11/30, dan tran <dantran@gmail.com
> <ma...@gmail.com> <mailto:dantran@gmail.com
> <ma...@gmail.com>>>:
>> >
>> >
>> >
>> > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> <ma...@gmail.com>
>> > <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>>> wrote:
>> >
>> > Good suggestions there Dan! It is indeed platform
> dependant and
>> > following the maven 2 way, we should be able to put
> those things
>> > in the settings.xml. Is that possible? That way,
> it's not needed
>> > anymore in the scm url.
>> >
>> >
>> > Unfortunatly we dont have access to setting.xml from
> maven-scm.
>> > Therefore we may endup
>> > implementing access to setting.xml in both
> maven-scm-plugin and
>> > maven-release-plugin.
>> > We may be able to replace release:perform step with
> scm:bootstrap.
>> > So only one place has
>> > the setting info. However I dont know if settings.xml
> has room for
>> > this type of user preferences.
>> >
>> >
>> > Should we mail Brett or someone else about this?
>>
>> I don't want to access to settings.xml in maven-scm.
> setting.xml in a maven2
>> file and maven-scm can
>> be use without it, so i think it isn't a good idea to create a
> maven2 file
>> for an independant tool.
>> If clearcase infos can't be specified in scm url, i think it's
> better to use
>> system property or we
>> can read an environment variable like CLEARCASE_VIEW_STORE_PATH
>
> My .02: I would want all config info in the config files. Not
> env vars, etc.
> For homogenous environments, each user can get the info from the
> source
> controlled config files.
>
>
>> > Does Continuum 'checkout' the code, builds and then removes
> the working
>> > directory again? Or does the working directory remain and is
> there some
>> > kind of update command that should happen?
>>
>> We don't remove working directory actually, and we update this
> directory in
>> each build. In future
>> version, continuum users will can choose to update or checkout
> sources. For
>> example update for
>> hourly builds and full checkout for nightly builds
>
> Just FYI - Perforce requires a "remove from workspace" to remove
> all the files
> locally, as it tracks all file versions it gives each
> user. This is why
> updates are so blazingly faster than its competition. One can
> manually delete
> the files, but Perforce will still think you have them. A
> Perforce user does
> the same action for a "update get latest" and a "full get
> latest": just a
> sync/get latest. Removing all the files and then doing a get
> latest will have
> the same end result, just take a lot longer!
>
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
I like that. I agree that we should not (ab)use settings.xml for a custom
plugin. If we now agree on the format for the file, we are set to go :)
Let me whip up an example:
<clearcase>
<viewstore>\\${hostname}\viewstore</viewstore>
</clearcase>
If we could pull this off, then probably all users in a certain company
could use the same file. If we can't figure out the hostname, then we will
need to have a different file for each user.
regards,
Wim
2005/11/30, dan tran <da...@gmail.com>:
>
> It makes me feel better. Perhaps we can get clearcase provider to look
> for a property file under ${user.home}.
> Shall it be ${user.home}/.m2/clearcase-settings.xml ?
>
> -D
>
>
>
> On 11/30/05, Jeff Jensen <je...@upstairstechnology.com> wrote:
> >
> > Quoting Emmanuel Venisse <em...@venisse.net>:
> >
> > >
> > >
> > > Wim Deblauwe a écrit :
> > > >
> > > >
> > > > 2005/11/30, dan tran <dantran@gmail.com <mailto:dantran@gmail.com
> > >>:
> > > >
> > > >
> > > >
> > > > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> > > > <mailto: wim.deblauwe@gmail.com>> wrote:
> > > >
> > > > Good suggestions there Dan! It is indeed platform dependant
> > and
> > > > following the maven 2 way, we should be able to put those
> > things
> > > > in the settings.xml. Is that possible? That way, it's not
> > needed
> > > > anymore in the scm url.
> > > >
> > > >
> > > > Unfortunatly we dont have access to setting.xml from
> > maven-scm.
> > > > Therefore we may endup
> > > > implementing access to setting.xml in both maven-scm-plugin and
> > > > maven-release-plugin.
> > > > We may be able to replace release:perform step with
> > scm:bootstrap.
> > > > So only one place has
> > > > the setting info. However I dont know if settings.xml has room
> > for
> > > > this type of user preferences.
> > > >
> > > >
> > > > Should we mail Brett or someone else about this?
> > >
> > > I don't want to access to settings.xml in maven-scm. setting.xml in a
> > maven2
> > > file and maven-scm can
> > > be use without it, so i think it isn't a good idea to create a maven2
> > file
> > > for an independant tool.
> > > If clearcase infos can't be specified in scm url, i think it's better
> > to use
> > > system property or we
> > > can read an environment variable like CLEARCASE_VIEW_STORE_PATH
> >
> > My .02: I would want all config info in the config files. Not env vars,
> > etc.
> > For homogenous environments, each user can get the info from the source
> > controlled config files.
> >
> >
> > > > Does Continuum 'checkout' the code, builds and then removes the
> > working
> > > > directory again? Or does the working directory remain and is there
> > some
> > > > kind of update command that should happen?
> > >
> > > We don't remove working directory actually, and we update this
> > directory in
> > > each build. In future
> > > version, continuum users will can choose to update or checkout
> > sources. For
> > > example update for
> > > hourly builds and full checkout for nightly builds
> >
> > Just FYI - Perforce requires a "remove from workspace" to remove all the
> > files
> > locally, as it tracks all file versions it gives each user. This is why
> >
> > updates are so blazingly faster than its competition. One can manually
> > delete
> > the files, but Perforce will still think you have them. A Perforce user
> > does
> > the same action for a "update get latest" and a "full get latest": just
> > a
> > sync/get latest. Removing all the files and then doing a get latest
> > will have
> > the same end result, just take a lot longer!
> >
> >
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
It makes me feel better. Perhaps we can get clearcase provider to look for
a property file under ${user.home}.
Shall it be ${user.home}/.m2/clearcase-settings.xml ?
-D
On 11/30/05, Jeff Jensen <je...@upstairstechnology.com> wrote:
>
> Quoting Emmanuel Venisse <em...@venisse.net>:
>
> >
> >
> > Wim Deblauwe a écrit :
> > >
> > >
> > > 2005/11/30, dan tran <dantran@gmail.com <ma...@gmail.com>>:
> > >
> > >
> > >
> > > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> > > <ma...@gmail.com>> wrote:
> > >
> > > Good suggestions there Dan! It is indeed platform dependant
> and
> > > following the maven 2 way, we should be able to put those
> things
> > > in the settings.xml. Is that possible? That way, it's not
> needed
> > > anymore in the scm url.
> > >
> > >
> > > Unfortunatly we dont have access to setting.xml from maven-scm.
> > > Therefore we may endup
> > > implementing access to setting.xml in both maven-scm-plugin and
> > > maven-release-plugin.
> > > We may be able to replace release:perform step with scm:bootstrap.
> > > So only one place has
> > > the setting info. However I dont know if settings.xml has room
> for
> > > this type of user preferences.
> > >
> > >
> > > Should we mail Brett or someone else about this?
> >
> > I don't want to access to settings.xml in maven-scm. setting.xml in a
> maven2
> > file and maven-scm can
> > be use without it, so i think it isn't a good idea to create a maven2
> file
> > for an independant tool.
> > If clearcase infos can't be specified in scm url, i think it's better to
> use
> > system property or we
> > can read an environment variable like CLEARCASE_VIEW_STORE_PATH
>
> My .02: I would want all config info in the config files. Not env vars,
> etc.
> For homogenous environments, each user can get the info from the source
> controlled config files.
>
>
> > > Does Continuum 'checkout' the code, builds and then removes the
> working
> > > directory again? Or does the working directory remain and is there
> some
> > > kind of update command that should happen?
> >
> > We don't remove working directory actually, and we update this directory
> in
> > each build. In future
> > version, continuum users will can choose to update or checkout sources.
> For
> > example update for
> > hourly builds and full checkout for nightly builds
>
> Just FYI - Perforce requires a "remove from workspace" to remove all the
> files
> locally, as it tracks all file versions it gives each user. This is why
> updates are so blazingly faster than its competition. One can manually
> delete
> the files, but Perforce will still think you have them. A Perforce user
> does
> the same action for a "update get latest" and a "full get latest": just a
> sync/get latest. Removing all the files and then doing a get latest will
> have
> the same end result, just take a lot longer!
>
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
On 11/30/05, Wim Deblauwe <wi...@gmail.com> wrote:
>
>
> 2005/11/30, dan tran <da...@gmail.com>:
> >
> >
> >
> > On 11/30/05, Wim Deblauwe < wim.deblauwe@gmail.com > wrote:
> > >
> > > Good suggestions there Dan! It is indeed platform dependant and
> > > following the maven 2 way, we should be able to put those things in the
> > > settings.xml. Is that possible? That way, it's not needed anymore in
> > > the scm url.
> >
> >
> > Unfortunatly we dont have access to setting.xml from maven-scm.
> > Therefore we may endup
> > implementing access to setting.xml in both maven-scm-plugin and
> > maven-release-plugin.
> > We may be able to replace release:perform step with scm:bootstrap. So
> > only one place has
> > the setting info. However I dont know if settings.xml has room for this
> > type of user preferences.
> >
>
> Should we mail Brett or someone else about this?
>
You can open JIRA request for this.
> On the view name: shouldn't we include the artifactId also. What if
> > > Continuum wants to build 2 projects? It will need to create 2 views and they
> > > cannot have the same name.
> >
> >
> > This will solve your case. I do have case where I want to run same
> > project on diffirent schedules
> > ( ie one for snapshot build happen every hr, one for release build every
> > night). In this case,
> > we have view name collision. This is a tough case to solve. we can try
> > to genereate a unique
> > view name if userer does not specify a view name. However in this case,
> > who is responsible
> > to remove the view after build is done? maven-scm creates it, then it
> > should allow method to
> > remove it.
> >
> > But let's go with ${hostname}-{user.name}-${artifactId} first. Cant
> > discuss forever ;-)
> >
>
> Does Continuum 'checkout' the code, builds and then removes the working
> directory again? Or does the working directory remain and is there some kind
> of update command that should happen?
>
Continum first does a checkout, then from there on issue update and
changelog to detect changes.
However if your config spec changes, the update command will need to sync
with changes in
config spec file. In UCM the command is cleartool setcs -stream.(wonder if
this command apply to base scm)
> about config spec file, i guest you ignore this file at release:perform
> > time right?
> > since you will generate your own spec file base on a label right?
> >
>
> Yes, very true. We should ignore it, if there is a non-null tag in the
> checkout command.
>
>
> regards,
>
> Wim
>
Re: ClearCase 'checkout' implementation
Posted by Jeff Jensen <je...@upstairstechnology.com>.
Quoting Emmanuel Venisse <em...@venisse.net>:
>
>
> Wim Deblauwe a écrit :
> >
> >
> > 2005/11/30, dan tran <dantran@gmail.com <ma...@gmail.com>>:
> >
> >
> >
> > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Good suggestions there Dan! It is indeed platform dependant and
> > following the maven 2 way, we should be able to put those things
> > in the settings.xml. Is that possible? That way, it's not needed
> > anymore in the scm url.
> >
> >
> > Unfortunatly we dont have access to setting.xml from maven-scm.
> > Therefore we may endup
> > implementing access to setting.xml in both maven-scm-plugin and
> > maven-release-plugin.
> > We may be able to replace release:perform step with scm:bootstrap.
> > So only one place has
> > the setting info. However I dont know if settings.xml has room for
> > this type of user preferences.
> >
> >
> > Should we mail Brett or someone else about this?
>
> I don't want to access to settings.xml in maven-scm. setting.xml in a maven2
> file and maven-scm can
> be use without it, so i think it isn't a good idea to create a maven2 file
> for an independant tool.
> If clearcase infos can't be specified in scm url, i think it's better to use
> system property or we
> can read an environment variable like CLEARCASE_VIEW_STORE_PATH
My .02: I would want all config info in the config files. Not env vars, etc.
For homogenous environments, each user can get the info from the source
controlled config files.
> > Does Continuum 'checkout' the code, builds and then removes the working
> > directory again? Or does the working directory remain and is there some
> > kind of update command that should happen?
>
> We don't remove working directory actually, and we update this directory in
> each build. In future
> version, continuum users will can choose to update or checkout sources. For
> example update for
> hourly builds and full checkout for nightly builds
Just FYI - Perforce requires a "remove from workspace" to remove all the files
locally, as it tracks all file versions it gives each user. This is why
updates are so blazingly faster than its competition. One can manually delete
the files, but Perforce will still think you have them. A Perforce user does
the same action for a "update get latest" and a "full get latest": just a
sync/get latest. Removing all the files and then doing a get latest will have
the same end result, just take a lot longer!
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
Wim Deblauwe a écrit :
>
>
> 2005/11/30, dan tran <dantran@gmail.com <ma...@gmail.com>>:
>
>
>
> On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> <ma...@gmail.com>> wrote:
>
> Good suggestions there Dan! It is indeed platform dependant and
> following the maven 2 way, we should be able to put those things
> in the settings.xml. Is that possible? That way, it's not needed
> anymore in the scm url.
>
>
> Unfortunatly we dont have access to setting.xml from maven-scm.
> Therefore we may endup
> implementing access to setting.xml in both maven-scm-plugin and
> maven-release-plugin.
> We may be able to replace release:perform step with scm:bootstrap.
> So only one place has
> the setting info. However I dont know if settings.xml has room for
> this type of user preferences.
>
>
> Should we mail Brett or someone else about this?
I don't want to access to settings.xml in maven-scm. setting.xml in a maven2 file and maven-scm can
be use without it, so i think it isn't a good idea to create a maven2 file for an independant tool.
If clearcase infos can't be specified in scm url, i think it's better to use system property or we
can read an environment variable like CLEARCASE_VIEW_STORE_PATH
>
> On the view name: shouldn't we include the artifactId also. What
> if Continuum wants to build 2 projects? It will need to create 2
> views and they cannot have the same name.
>
>
> This will solve your case. I do have case where I want to run same
> project on diffirent schedules
> ( ie one for snapshot build happen every hr, one for release build
> every night). In this case,
> we have view name collision. This is a tough case to solve. we can
> try to genereate a unique
> view name if userer does not specify a view name. However in this
> case, who is responsible
> to remove the view after build is done? maven-scm creates it, then
> it should allow method to
> remove it.
>
> But let's go with ${hostname}-{user.name
> <http://user.name>}-${artifactId} first. Cant discuss forever ;-)
>
>
> Does Continuum 'checkout' the code, builds and then removes the working
> directory again? Or does the working directory remain and is there some
> kind of update command that should happen?
We don't remove working directory actually, and we update this directory in each build. In future
version, continuum users will can choose to update or checkout sources. For example update for
hourly builds and full checkout for nightly builds
>
> about config spec file, i guest you ignore this file at
> release:perform time right?
> since you will generate your own spec file base on a label right?
>
>
> Yes, very true. We should ignore it, if there is a non-null tag in the
> checkout command.
>
> regards,
>
> Wim
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
2005/11/30, dan tran <da...@gmail.com>:
>
>
>
> On 11/30/05, Wim Deblauwe <wi...@gmail.com> wrote:
> >
> > Good suggestions there Dan! It is indeed platform dependant and
> > following the maven 2 way, we should be able to put those things in the
> > settings.xml. Is that possible? That way, it's not needed anymore in the
> > scm url.
>
>
> Unfortunatly we dont have access to setting.xml from maven-scm.
> Therefore we may endup
> implementing access to setting.xml in both maven-scm-plugin and
> maven-release-plugin.
> We may be able to replace release:perform step with scm:bootstrap. So only
> one place has
> the setting info. However I dont know if settings.xml has room for this
> type of user preferences.
>
Should we mail Brett or someone else about this?
On the view name: shouldn't we include the artifactId also. What if
> > Continuum wants to build 2 projects? It will need to create 2 views and they
> > cannot have the same name.
>
>
> This will solve your case. I do have case where I want to run same
> project on diffirent schedules
> ( ie one for snapshot build happen every hr, one for release build every
> night). In this case,
> we have view name collision. This is a tough case to solve. we can try to
> genereate a unique
> view name if userer does not specify a view name. However in this case,
> who is responsible
> to remove the view after build is done? maven-scm creates it, then it
> should allow method to
> remove it.
>
> But let's go with ${hostname}-{user.name}-${artifactId} first. Cant
> discuss forever ;-)
>
Does Continuum 'checkout' the code, builds and then removes the working
directory again? Or does the working directory remain and is there some kind
of update command that should happen?
about config spec file, i guest you ignore this file at release:perform time
> right?
> since you will generate your own spec file base on a label right?
>
Yes, very true. We should ignore it, if there is a non-null tag in the
checkout command.
regards,
Wim
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
On 11/30/05, Wim Deblauwe <wi...@gmail.com> wrote:
>
> Good suggestions there Dan! It is indeed platform dependant and following
> the maven 2 way, we should be able to put those things in the settings.xml.
> Is that possible? That way, it's not needed anymore in the scm url.
Unfortunatly we dont have access to setting.xml from maven-scm. Therefore
we may endup
implementing access to setting.xml in both maven-scm-plugin and
maven-release-plugin.
We may be able to replace release:perform step with scm:bootstrap. So only
one place has
the setting info. However I dont know if settings.xml has room for this
type of user preferences.
On the view name: shouldn't we include the artifactId also. What if
> Continuum wants to build 2 projects? It will need to create 2 views and they
> cannot have the same name.
This will solve your case. I do have case where I want to run same project
on diffirent schedules
( ie one for snapshot build happen every hr, one for release build every
night). In this case,
we have view name collision. This is a tough case to solve. we can try to
genereate a unique
view name if userer does not specify a view name. However in this case, who
is responsible
to remove the view after build is done? maven-scm creates it, then it
should allow method to
remove it.
But let's go with ${hostname}-{user.name}-${artifactId} first. Cant discuss
forever ;-)
about config spec file, i guest you ignore this file at release:perform time
right?
since you will generate your own spec file base on a label right?
-D
For path_to_confgspec we could use the file:// url to avoid platform
> dependencies.
>
> So my example would become:
>
> scm:clearcase:basescm:file://///someserver/ClearCase/myproject/configspec.txt
>
>
> or with the optional param for the view:
>
> scm:clearcase:basescm:my_very_own_view:file://///someserver/ClearCase/myproject/configspec.txt
>
>
> regards,
>
> Wim
>
>
>
> 2005/11/30, dan tran <da...@gmail.com>:
> >
> > Wim,
> >
> > - Path to view store should be in system properties since it is
> > Platform dependent.
> > Windows and unix use different paths and depend on per station/user.
> >
> > We can default the viewstore to some paths, again unix windows are
> > diffrent.
> >
> > I would suggest that
> >
> > \\${hostname}\viewstore for windows
> >
> > /usr/scm/viewstore for unix
> >
> >
> >
> > -In order to checkout, we need a view name. we can have a convention
> > of
> >
> > of default to ${hostname}-${username}-maven
> >
> > -We have the same problem to path-to-configspec. However a using http
> > URL may solve it
> >
> >
> > So for the base SCM, your case the URL is like this
> >
> > scm:clearcase:basescm:[viewname]:path-to-configspec
> >
> > I am not sure about path-to-configspec, since in my case it is in
> > another SCM vob. ;(
> >
> >
> > I am still having trouble of gathering my thoughts on implementing my
> > UCM-SCM.
> > It even more complicated compare to base SCM ;(, since it deals with
> > clearcase streams
> > and projects
> >
> > -Dan
> >
> >
> >
> >
> > On 11/30/05, Emmanuel Venisse <emmanuel@venisse.net > wrote:
> > >
> > > With clearcase, do you have an environment variables that define the
> > > path to viewstore?
> > >
> > > Wim Deblauwe a écrit :
> > > > Hmm.. this is hard to explain if you don't know clearcase, but I'll
> > > try:
> > > >
> > > > 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 < emmanuel@venisse.net
> > > > <mailto:emmanuel@venisse.net >>:
> > > >
> > > > 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 <wim.deblauwe@gmail.com
> > > > <mailto:wim.deblauwe@gmail.com >
> > > > > <mailto:wim.deblauwe@gmail.com <mailto:wim.deblauwe@gmail.com
> > > >>>:
> > > > >
> > > > > 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
> > > >
> > > > >
> > > > <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 < dantran@gmail.com
> > > > <mailto: dantran@gmail.com > <mailto:dantran@gmail.com
> > > > <mailto:dantran@gmail.com >>>:
> > > > >
> > > > > 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* < wim.deblauwe@gmail.com
> > > > <mailto:wim.deblauwe@gmail.com >
> > > > > <mailto:wim.deblauwe@gmail.com
> > > > <mailto:wim.deblauwe@gmail.com >>> 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 <
> > > emmanuel@venisse.net
> > > > <mailto:emmanuel@venisse.net >
> > > > > <mailto: emmanuel@venisse.net
> > > > <mailto:emmanuel@venisse.net >>>:
> > > > >
> > > > >
> > > > >
> > > > > dan tran a écrit :
> > > > >>
> > > > >>
> > > > >> On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> > > > <mailto: emmanuel@venisse.net >
> > > > > <mailto:emmanuel@venisse.net
> > > > <mailto:emmanuel@venisse.net >>
> > > > >> <mailto:emmanuel@venisse.net <mailto:emmanuel@venisse.net >
> > > > > <mailto: emmanuel@venisse.net
> > > > <mailto:emmanuel@venisse.net >>>> 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* <
> > > > > wim.deblauwe@gmail.com
> > > > <mailto: wim.deblauwe@gmail.com > <mailto:wim.deblauwe@gmail.com
> > > > <mailto:wim.deblauwe@gmail.com >>
> > > > >> <mailto: wim.deblauwe@gmail.com <mailto:
> > > wim.deblauwe@gmail.com >
> > > > > <mailto: wim.deblauwe@gmail.com
> > > > <mailto:wim.deblauwe@gmail.com >>>
> > > > >> > <mailto: wim.deblauwe@gmail.com
> > > > <mailto:wim.deblauwe@gmail.com >
> > > > > <mailto:wim.deblauwe@gmail.com
> > > > <mailto: wim.deblauwe@gmail.com >> <mailto:
> > > > > wim.deblauwe@gmail.com
> > > > <mailto: wim.deblauwe@gmail.com > <mailto:
> > > wim.deblauwe@gmail.com
> > > > <mailto:wim.deblauwe@gmail.com >>>>>
> > > > >> 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
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
Good suggestions there Dan! It is indeed platform dependant and following
the maven 2 way, we should be able to put those things in the settings.xml.
Is that possible? That way, it's not needed anymore in the scm url.
On the view name: shouldn't we include the artifactId also. What if
Continuum wants to build 2 projects? It will need to create 2 views and they
cannot have the same name.
For path_to_confgspec we could use the file:// url to avoid platform
dependencies.
So my example would become:
scm:clearcase:basescm:
file://///someserver/ClearCase/myproject/configspec.txt
or with the optional param for the view:
scm:clearcase:basescm:my_very_own_view:
file://///someserver/ClearCase/myproject/configspec.txt
regards,
Wim
2005/11/30, dan tran <da...@gmail.com>:
>
> Wim,
>
> - Path to view store should be in system properties since it is Platform
> dependent.
> Windows and unix use different paths and depend on per station/user.
>
> We can default the viewstore to some paths, again unix windows are
> diffrent.
>
> I would suggest that
>
> \\${hostname}\viewstore for windows
>
> /usr/scm/viewstore for unix
>
>
>
> -In order to checkout, we need a view name. we can have a convention of
>
>
> of default to ${hostname}-${username}-maven
>
> -We have the same problem to path-to-configspec. However a using http
> URL may solve it
>
>
> So for the base SCM, your case the URL is like this
>
> scm:clearcase:basescm:[viewname]:path-to-configspec
>
> I am not sure about path-to-configspec, since in my case it is in another
> SCM vob. ;(
>
>
> I am still having trouble of gathering my thoughts on implementing my
> UCM-SCM.
> It even more complicated compare to base SCM ;(, since it deals with
> clearcase streams
> and projects
>
> -Dan
>
>
>
>
> On 11/30/05, Emmanuel Venisse <em...@venisse.net> wrote:
> >
> > With clearcase, do you have an environment variables that define the
> > path to viewstore?
> >
> > Wim Deblauwe a écrit :
> > > Hmm.. this is hard to explain if you don't know clearcase, but I'll
> > try:
> > >
> > > 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 < emmanuel@venisse.net
> > > <ma...@venisse.net>>:
> > >
> > > 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 <wim.deblauwe@gmail.com
> > > <mailto:wim.deblauwe@gmail.com >
> > > > <mailto:wim.deblauwe@gmail.com <mailto:wim.deblauwe@gmail.com
> > >>>:
> > > >
> > > > 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
> > >
> > > >
> > > <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 <dantran@gmail.com
> > > <mailto: dantran@gmail.com> <mailto:dantran@gmail.com
> > > <ma...@gmail.com>>>:
> > > >
> > > > 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* < wim.deblauwe@gmail.com
> > > <ma...@gmail.com>
> > > > <mailto:wim.deblauwe@gmail.com
> > > <ma...@gmail.com>>> 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 < emmanuel@venisse.net
> > > <ma...@venisse.net>
> > > > <mailto: emmanuel@venisse.net
> > > <ma...@venisse.net>>>:
> > > >
> > > >
> > > >
> > > > dan tran a écrit :
> > > >>
> > > >>
> > > >> On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> > > <mailto: emmanuel@venisse.net>
> > > > <mailto:emmanuel@venisse.net
> > > <mailto:emmanuel@venisse.net >>
> > > >> <mailto:emmanuel@venisse.net <ma...@venisse.net>
> > > > <mailto: emmanuel@venisse.net
> > > <ma...@venisse.net>>>> 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* <
> > > > wim.deblauwe@gmail.com
> > > <mailto: wim.deblauwe@gmail.com> <mailto:wim.deblauwe@gmail.com
> > > <ma...@gmail.com>>
> > > >> <mailto: wim.deblauwe@gmail.com <mailto:
> > wim.deblauwe@gmail.com>
> > > > <mailto: wim.deblauwe@gmail.com
> > > <ma...@gmail.com>>>
> > > >> > <mailto: wim.deblauwe@gmail.com
> > > <ma...@gmail.com>
> > > > <mailto:wim.deblauwe@gmail.com
> > > <mailto: wim.deblauwe@gmail.com>> <mailto:
> > > > wim.deblauwe@gmail.com
> > > <mailto: wim.deblauwe@gmail.com> <mailto: wim.deblauwe@gmail.com
> > > <ma...@gmail.com>>>>>
> > > >> 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
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
Wim,
- Path to view store should be in system properties since it is Platform
dependent.
Windows and unix use different paths and depend on per station/user.
We can default the viewstore to some paths, again unix windows are
diffrent.
I would suggest that
\\${hostname}\viewstore for windows
/usr/scm/viewstore for unix
-In order to checkout, we need a view name. we can have a convention of
of default to ${hostname}-${username}-maven
-We have the same problem to path-to-configspec. However a using http URL
may solve it
So for the base SCM, your case the URL is like this
scm:clearcase:basescm:[viewname]:path-to-configspec
I am not sure about path-to-configspec, since in my case it is in another
SCM vob. ;(
I am still having trouble of gathering my thoughts on implementing my
UCM-SCM.
It even more complicated compare to base SCM ;(, since it deals with
clearcase streams
and projects
-Dan
On 11/30/05, Emmanuel Venisse <em...@venisse.net> wrote:
>
> With clearcase, do you have an environment variables that define the path
> to viewstore?
>
> Wim Deblauwe a écrit :
> > Hmm.. this is hard to explain if you don't know clearcase, but I'll try:
> >
> > 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 <emmanuel@venisse.net
> > <ma...@venisse.net>>:
> >
> > 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 <wim.deblauwe@gmail.com
> > <ma...@gmail.com>
> > > <mailto:wim.deblauwe@gmail.com <ma...@gmail.com>>>:
> > >
> > > 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
> >
> > >
> > <
> 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 <dantran@gmail.com
> > <ma...@gmail.com> <mailto:dantran@gmail.com
> > <ma...@gmail.com>>>:
> > >
> > > 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* < wim.deblauwe@gmail.com
> > <ma...@gmail.com>
> > > <mailto:wim.deblauwe@gmail.com
> > <ma...@gmail.com>>> 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 <emmanuel@venisse.net
> > <ma...@venisse.net>
> > > <mailto: emmanuel@venisse.net
> > <ma...@venisse.net>>>:
> > >
> > >
> > >
> > > dan tran a écrit :
> > >>
> > >>
> > >> On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> > <ma...@venisse.net>
> > > <mailto:emmanuel@venisse.net
> > <ma...@venisse.net>>
> > >> <mailto:emmanuel@venisse.net <ma...@venisse.net>
> > > <mailto: emmanuel@venisse.net
> > <ma...@venisse.net>>>> 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* <
> > > wim.deblauwe@gmail.com
> > <ma...@gmail.com> <mailto:wim.deblauwe@gmail.com
> > <ma...@gmail.com>>
> > >> <mailto: wim.deblauwe@gmail.com <mailto:
> wim.deblauwe@gmail.com>
> > > <mailto:wim.deblauwe@gmail.com
> > <ma...@gmail.com>>>
> > >> > <mailto: wim.deblauwe@gmail.com
> > <ma...@gmail.com>
> > > <mailto:wim.deblauwe@gmail.com
> > <ma...@gmail.com>> <mailto:
> > > wim.deblauwe@gmail.com
> > <ma...@gmail.com> <mailto: wim.deblauwe@gmail.com
> > <ma...@gmail.com>>>>>
> > >> 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
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
With clearcase, do you have an environment variables that define the path to viewstore?
Wim Deblauwe a écrit :
> Hmm.. this is hard to explain if you don't know clearcase, but I'll try:
>
> 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 <emmanuel@venisse.net
> <ma...@venisse.net>>:
>
> 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 <wim.deblauwe@gmail.com
> <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com <ma...@gmail.com>>>:
> >
> > 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>
> >
> <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 <dantran@gmail.com
> <ma...@gmail.com> <mailto:dantran@gmail.com
> <ma...@gmail.com>>>:
> >
> > 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* < wim.deblauwe@gmail.com
> <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>> 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 <emmanuel@venisse.net
> <ma...@venisse.net>
> > <mailto: emmanuel@venisse.net
> <ma...@venisse.net>>>:
> >
> >
> >
> > dan tran a écrit :
> >>
> >>
> >> On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> <ma...@venisse.net>
> > <mailto:emmanuel@venisse.net
> <ma...@venisse.net>>
> >> <mailto:emmanuel@venisse.net <ma...@venisse.net>
> > <mailto: emmanuel@venisse.net
> <ma...@venisse.net>>>> 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* <
> > wim.deblauwe@gmail.com
> <ma...@gmail.com> <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>
> >> <mailto: wim.deblauwe@gmail.com <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>>
> >> > <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>> <mailto:
> > wim.deblauwe@gmail.com
> <ma...@gmail.com> <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>>>>>
> >> 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
> >> >
> >> >
> >>
> >>
> >
> >
> >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
ok. It's clear.
If you include the path to view store, in scm url, each developer will must be have their viewstore
in this path. If not, they can't use the scm plugin.
Emmanuel
Wim Deblauwe a écrit :
> Hmm.. this is hard to explain if you don't know clearcase, but I'll try:
>
> 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 <emmanuel@venisse.net
> <ma...@venisse.net>>:
>
> 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 <wim.deblauwe@gmail.com
> <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com <ma...@gmail.com>>>:
> >
> > 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>
> >
> <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 <dantran@gmail.com
> <ma...@gmail.com> <mailto:dantran@gmail.com
> <ma...@gmail.com>>>:
> >
> > 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* < wim.deblauwe@gmail.com
> <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>> 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 <emmanuel@venisse.net
> <ma...@venisse.net>
> > <mailto: emmanuel@venisse.net
> <ma...@venisse.net>>>:
> >
> >
> >
> > dan tran a écrit :
> >>
> >>
> >> On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> <ma...@venisse.net>
> > <mailto:emmanuel@venisse.net
> <ma...@venisse.net>>
> >> <mailto:emmanuel@venisse.net <ma...@venisse.net>
> > <mailto: emmanuel@venisse.net
> <ma...@venisse.net>>>> 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* <
> > wim.deblauwe@gmail.com
> <ma...@gmail.com> <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>
> >> <mailto: wim.deblauwe@gmail.com <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>>
> >> > <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>> <mailto:
> > wim.deblauwe@gmail.com
> <ma...@gmail.com> <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>>>>>
> >> 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
> >> >
> >> >
> >>
> >>
> >
> >
> >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
Hmm.. this is hard to explain if you don't know clearcase, but I'll try:
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 <em...@venisse.net>:
>
> 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 <wim.deblauwe@gmail.com
> > <ma...@gmail.com>>:
> >
> > 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 <dantran@gmail.com <ma...@gmail.com>>:
> >
> > 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* <wim.deblauwe@gmail.com
> > <ma...@gmail.com>> 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 <emmanuel@venisse.net
> > <ma...@venisse.net>>:
> >
> >
> >
> > dan tran a écrit :
> >>
> >>
> >> On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> > <ma...@venisse.net>
> >> <mailto:emmanuel@venisse.net
> > <ma...@venisse.net>>> 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* <
> > wim.deblauwe@gmail.com <ma...@gmail.com>
> >> <mailto:wim.deblauwe@gmail.com
> > <ma...@gmail.com>>
> >> > <mailto: wim.deblauwe@gmail.com
> > <ma...@gmail.com> <mailto:
> > wim.deblauwe@gmail.com <mailto:wim.deblauwe@gmail.com
> >>>>
> >> 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
> >> >
> >> >
> >>
> >>
> >
> >
> >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
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 <wim.deblauwe@gmail.com
> <ma...@gmail.com>>:
>
> 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 <dantran@gmail.com <ma...@gmail.com>>:
>
> 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* <wim.deblauwe@gmail.com
> <ma...@gmail.com>> 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 <emmanuel@venisse.net
> <ma...@venisse.net>>:
>
>
>
> dan tran a écrit :
>>
>>
>> On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> <ma...@venisse.net>
>> <mailto:emmanuel@venisse.net
> <ma...@venisse.net>>> 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* <
> wim.deblauwe@gmail.com <ma...@gmail.com>
>> <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>
>> > <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com> <mailto:
> wim.deblauwe@gmail.com <ma...@gmail.com>>>>
>> 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
>> >
>> >
>>
>>
>
>
>
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
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 <wi...@gmail.com>:
>
> For information: 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 <da...@gmail.com>:
> >
> > 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 <wim.deblauwe@gmail.com > 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 <emmanuel@venisse.net >:
> > > >
> > > >
> > > >
> > > > dan tran a écrit :
> > > > >
> > > > >
> > > > > On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> > > > > <mailto:emmanuel@venisse.net >> 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* < wim.deblauwe@gmail.com
> > > > > <mailto:wim.deblauwe@gmail.com >
> > > > > > <mailto: wim.deblauwe@gmail.com <mailto:
> > > > wim.deblauwe@gmail.com >>>
> > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
For information:
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 <da...@gmail.com>:
>
> 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 <wi...@gmail.com> 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 <em...@venisse.net>:
> > >
> > >
> > >
> > > dan tran a écrit :
> > > >
> > > >
> > > > On 11/24/05, *Emmanuel Venisse* < emmanuel@venisse.net
> > > > <mailto:emmanuel@venisse.net >> 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* < wim.deblauwe@gmail.com
> > > > <ma...@gmail.com>
> > > > > <mailto: wim.deblauwe@gmail.com <mailto:
> > > wim.deblauwe@gmail.com>>>
> > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
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 <wi...@gmail.com> 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 <em...@venisse.net>:
> >
> >
> >
> > dan tran a écrit :
> > >
> > >
> > > On 11/24/05, *Emmanuel Venisse* <emmanuel@venisse.net
> > > <mailto:emmanuel@venisse.net >> 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* < wim.deblauwe@gmail.com
> > > <ma...@gmail.com>
> > > > <mailto:wim.deblauwe@gmail.com <mailto: wim.deblauwe@gmail.com
> > >>>
> > > 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
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
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 <em...@venisse.net>:
>
>
>
> dan tran a écrit :
> >
> >
> > On 11/24/05, *Emmanuel Venisse* <emmanuel@venisse.net
> > <ma...@venisse.net>> 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* <wim.deblauwe@gmail.com
> > <ma...@gmail.com>
> > > <mailto:wim.deblauwe@gmail.com <ma...@gmail.com>>>
> > 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
> > >
> > >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
dan tran a écrit :
>
>
> On 11/24/05, *Emmanuel Venisse* <emmanuel@venisse.net
> <ma...@venisse.net>> 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* <wim.deblauwe@gmail.com
> <ma...@gmail.com>
> > <mailto:wim.deblauwe@gmail.com <ma...@gmail.com>>>
> 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
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
On 11/24/05, Emmanuel Venisse <em...@venisse.net> 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?
>
> > 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* <wim.deblauwe@gmail.com
> > <ma...@gmail.com>> 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
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
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 will be out to town with limited access to internet. Will discuss
> more when I get back.
>
> -D
>
>
>
>
> On 11/23/05, *Wim Deblauwe* <wim.deblauwe@gmail.com
> <ma...@gmail.com>> 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
>
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
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 will be out to town with limited access to internet. Will discuss more
when I get back.
-D
On 11/23/05, Wim Deblauwe <wi...@gmail.com> 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
>