ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stuart Hughes
Subject: Re: [Ltib] -m release and CVS ltib module
Date: Tue, 09 Mar 2010 08:39:35 +0000
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

Hi Andrea,

git support should be okay, adding the release mechanism was one of the
last things I did before leaving Freescale.  I've tested this many
times, but not made an "official" ISO using it.

Eventually LTIB will move to git, but compared to the disruption and the
small return it's not a priority given my current complete lack of time
and resources.

Regards, Stuart

Andrea Galbusera wrote:
> 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
>>>>>>>
>>>
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]