Re: [Ltib] -m release and CVS ltib module

[Stuart Hughes]

Hi Andrea,

I didn't really understand what you were proposing (what you mean by
sandbox in this context).

The release mechanism (for CVS) has been coded with the assumption of
one repository named ltib with releases against tag/branches.  I think
it would be easier to work within those constraints rather than to
change the model.

Regards, Stuart

Andrea Galbusera wrote:
> Stuart,
> 
> On Mon, 2010-03-08 at 10:31 +0000, Stuart Hughes wrote:
> 
>> * If you do use your own internal CVS, you should only have one CVS tree
>> and use tags/branches for releases.  Using a alias to allow you to refer
>> to "ltib" is probably the simplest approach.
> 
> I'm not expert in perl at all but... would not be possible to simply get
> the module name from CVS/Repository file in our sandbox? You are already
> testing the existence of CVS/ dir to understand what our CMS is, so it
> does not seem to add too much constrains. Do you believe it is
> reasonable/possible?
> 
> if(-d "$cf->{top}/CVS") {
>  system_nb("cvs export -kv -d $dir -r $tag ltib") == 0 or return;
> }
> 
> In fact the cvs command itself you are calling is already relying on
> metadata files in CVS/, i.e. to resolv the repository location. No idea
> why it is not doing the same with module names for cvs command executed
> inside a sandbox (maybe asking to some cvs guru would clarify).
> 
> This is just an idea I got and wanted to share with you. Forget it if it
> sounds stupid.
> 
> Regards,
> Andrea
> 
>> Andrea Galbusera wrote:
>>> Hi Stuart,
>>> I'm still experimenting with the '-m release' option of ltib.
>>>
>>> The problem I'm facing is in the 'CVS export' command that is embedded
>>> in the release procedure. As you may remember from my previous threads
>>> on the subject, I'm using a locally hosted CVS tree of ltib: the point
>>> seems to be that this tree in not uniquely called 'ltib' but something
>>> like 'myproject/mysubproject/ltib-something'. I suspect this is making
>>> the following code in Ltibutils.pm to do something unexpected.
>>>
>>>     if(-d "$cf->{top}/CVS") {
>>>         system_nb("cvs export -kv -d $dir -r $tag ltib") == 0 or return;
>>>     }
>>>
>>> In fact, this is not failing with an error but simply no $dir is created
>>> and nothing at all is exported. Following operations will than fail,
>>> since 'stage' dir is missing.
>>>
>>> I'd like to have your opinion on this... having a local CVS repository
>>> for ltib is supported (as discussed in previous threads), so I should
>>> not be too much out of path. To avoid changing anything in ltib, of
>>> course, I could enforce 'ltib' to be the name of the module in the
>>> repository or, at least, I could create an alias module (in the CVS
>>> meaning of this term) to make 'ltib' point at the right location in the
>>> repository. But what if more than one tree of ltib is present in the
>>> repository (as, in fact, is on my repository)? Is there any chance to
>>> instruct cvs to catch the module name from the sandbox it is run from?
>>>
>>> Thanks for your always precious help!
>>> Andrea
>>>
>>>
>>>
>>> _______________________________________________
>>> LTIB home page: http://ltib.org
>>>
>>> Ltib mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/ltib
>>>
> 
>