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

[Andrea Galbusera]

Stuart,
Thanks for reply. Let me comment a little bit more below.

On Mon, 2010-03-08 at 10:31 +0000, Stuart Hughes wrote:
> * Why not just use the Savannah CVS tree.  Are your changes really
> necessary and if so why not make them public.  It's your choice, but as
> you can see this problem would not arise if you were using the
> "official" tree.  If it's only your content that is private, that can be
> handled without changing the Savannah LTIB source code.

You are probably right. This is not a matter of keeping any particular
secret. I'm truly using mainline version of ltib, at least the tool
itself. But we'd like to keep platform configurations at home: no real
secrets even there but it is not always our choice. We also have some,
maybe dirty, patches to userspace applications. In order to release our
work as a standalone iso, I believe I will have to commit this to
Savannah. I sometime need to release even without the time to cleanup
things and public repository does not sound to me the perfect place for
such kind of commits. Another reason that is making me like local CVS is
the opportunity to selectively protect from mainline changes and still
support upgrades by vendor branches.

Everytime I find the necessary timeslots, I try to feedback the list
with any potential improvement / bug report, but this always require
more refinement than an internally-urgently-to-be-released hack or fix.

But if you can suggest a good development process that keeps platform
configuration and custom spec files locally, I will be glad to ear of
it.

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

At moment, we have more than one tree mainly for 'historical' reason.
Maybe I'll go with the alias module anyway, but I was curious if you
were planning to support any more control over the CVS module name in
the future. Thanks again for your detailed feedback.

Regards,
Andrea

> Regards, Stuart
> 
> 
> 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
> > 
>