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

[Andrea Galbusera]

Hi Stuart,
thanks for clarifying your point of view on the subject. Tonight I was
able to build the iso image with that little hack on the CVS module
name. For the moment I think I will stay with it, but I will consider
hooking to mainline for future projects. 

Even using git is stimulating me a lot... as soon as I have some time, I
will experiment with it. Is git support already mature in ltib?

Regards,
Andrea

On Mon, 2010-03-08 at 16:03 +0000, Stuart Hughes wrote:
> Hi Andrea,
> 
> I think you could use this, but it is not something I'd put into the
> mainstream.  The reason is that I want to make sure that releases come
> from the master repository, despite whatever a user has locally.  You
> can see a similar train of thought if you look at the handling for git.
>  Effort is made to make sure the tags are in the master repository.
> 
> Look at it another way, if you have multiple independent repositories,
> you end up with a lot of effort merging between them (or not and
> forking).  I'm trying to avoid this, I think you should too, but your
> own development process may cause you to adopt another policy.
> 
> Regards, Stuart
> 
> Andrea Galbusera wrote:
> > 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
> >>>>>
> >>>
> > 
> > 
>