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

[Andrea Galbusera]

Stuart,

On Mon, 2010-03-08 at 13:47 +0000, Stuart Hughes wrote:
> I didn't really understand what you were proposing (what you mean by
> sandbox in this context).

Since I have ltib under my local CVS repository, I run all ./ltib
commands from within a local copy (sandbox) of the ltib module from the
repository.

What I was suggesting was to simply deduce the 'local' module name from
CVS/Repository file. After writing to the list I then digged a while
more inside the code and noticed that you are doing exactly this inside
your cvsmanifest script.

I don't know if this can have any bad side-effect: I'm doing some test
with this trivial patch:

Index: bin/Ltibutils.pm
===================================================================
RCS file: /cvsroot/tpt2000/uel/ltib-tpt/bin/Ltibutils.pm,v
retrieving revision 1.2
diff -r1.2 Ltibutils.pm
1116a1117,1119
> # get the CVS module name from CVS/Repository file for non standard
naming
>               local $rep;
>               chomp($rep =`cat $cf->{top}/CVS/Repository`);
1118c1121
<         system_nb("cvs export -kv -d $dir -r $tag ltib") == 0 or
return;
---
>         system_nb("cvs export -kv -d $dir -r $tag $rep") == 0 or
return;

If you see any breakage of your original assumptions, please let me
know.

Regards,
Andrea

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