Unable to check out CVS modules

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Unable to check out CVS modules

Kayser, William H

Awesome product.  I’m cranking away on a Saturday converting our builds from Tinderbox to Hudson.  I just have one problem now.

 

I’ve struggled getting code checked out of CVS.  I have module definitions with –a options, like

 

main_project -a \

    products/main \

    products/buildsystem \

    products/etc

 

In this case, you get cvs errors like

 

cvs checkout: existing repository /usr/cvs/products/main does not match /usr/cvs/products/buildsystem…

 

The solution is to check the compatibility option, “flatten”, which causes the module to be checked out without the –d option to specify a directory. 

 

However this introduces a new problem.  When the module is checked out that way, there is no CVS directory created at the top (workspace) level.  There is a “products” folder but no CVS folder. 

 

As a result, the log command generates this error:

 

CVS/Entries for reading: No such file or directory cvs [log aborted]: no repository

 

I submitted a bug on the first problem before I discovered the workaround.  Before I submitted another bug I thought I’d see if anyone knew of a workaround for this problem.

 

Bill

 

Reply | Threaded
Open this post in threaded view
|

Re: Unable to check out CVS modules

Kohsuke Kawaguchi-2
Kayser, Bill wrote:

> Awesome product.  I'm cranking away on a Saturday converting our builds
> from Tinderbox to Hudson.  I just have one problem now.
>
>  
>
> I've struggled getting code checked out of CVS.  I have module
> definitions with -a options, like
>
>  
>
> main_project -a \
>
>     products/main \
>
>     products/buildsystem \
>
>     products/etc
>
>  
>
> In this case, you get cvs errors like
>
>  
>
> cvs checkout: existing repository /usr/cvs/products/main does not match
> /usr/cvs/products/buildsystem...
>
>  
>
> The solution is to check the compatibility option, "flatten", which
> causes the module to be checked out without the -d option to specify a
> directory.  
>
>  
>
> However this introduces a new problem.  When the module is checked out
> that way, there is no CVS directory created at the top (workspace)
> level.  There is a "products" folder but no CVS folder.
I believe that's the way CVS works with module aliases.


> As a result, the log command generates this error:
>
>  
>
> CVS/Entries for reading: No such file or directory cvs [log aborted]: no
> repository

I need to do some experiments, but I guess "cvs log main_project" is
failing and I suspect it's really the way CVS works.

Maybe Hudson can prepare for this possibility and be smart enough to run
"cvs log" with its subdirectories. But Hudson can't really know whether
something is an alias or not, so there might be some inherent problem
that we can't really solve. We'll have to see. I think a bug should be
definitely in order.

A work around would be to specify expanded list of modules in Hudson
("products/main products/buildsystem products/etc")

> I submitted a bug on the first problem before I discovered the
> workaround.  Before I submitted another bug I thought I'd see if anyone
> knew of a workaround for this problem.



--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re: Unable to check out CVS modules

Kayser, William H


> -----Original Message-----
> From: Kohsuke Kawaguchi [mailto:[hidden email]]
> Sent: Saturday, March 03, 2007 9:25 PM
> To: [hidden email]
> Subject: Re: Unable to check out CVS modules
>
> Kayser, Bill wrote:
> > However this introduces a new problem.  When the module is checked
out
> > CVS/Entries for reading: No such file or directory cvs [log
aborted]: no
> > repository
>
> I need to do some experiments, but I guess "cvs log main_project" is
> failing and I suspect it's really the way CVS works.
>

Agreed.  But I wonder why the module is even passed to the log command.
At that point the module has already been fetched.  If I execute a cvs
log in the workspace without specifying the module it seems to work
perfectly fine.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unable to check out CVS modules

Kohsuke Kawaguchi-2
Kayser, Bill wrote:

>
>> -----Original Message-----
>> From: Kohsuke Kawaguchi [mailto:[hidden email]]
>> Sent: Saturday, March 03, 2007 9:25 PM
>> To: [hidden email]
>> Subject: Re: Unable to check out CVS modules
>>
>> Kayser, Bill wrote:
>> > However this introduces a new problem.  When the module is checked
> out
>> > CVS/Entries for reading: No such file or directory cvs [log
> aborted]: no
>> > repository
>>
>> I need to do some experiments, but I guess "cvs log main_project" is
>> failing and I suspect it's really the way CVS works.
>>
>
> Agreed.  But I wonder why the module is even passed to the log command.
> At that point the module has already been fetched.
"cvs co main_project" will hit the server and realize that this is an
alias, so it can know that it's an alias when it actually gets to the work.

But "cvs log main_project" is a command that works against a working
directory, so that's why it fails. It just doesn't find ./CVS. That's my
theory anyway.

 > If I execute a cvs
 > log in the workspace without specifying the module it seems to work
 > perfectly fine.

Hmm. That contradicts with my theory. I guess I really need to experiment.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment