[ECOS] Keeping 2.0 source tree up to date

[ECOS] Keeping 2.0 source tree up to date

[Grant Edwards]

Whats the recommended way to keep a 2.0 source tree up to date
with bug fixes?

Do I need to try to get BOFH to allow access to the CVS tree?

Is there an official archive of approved patches somewhere that
can be downloaded?

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Andrew Lunn]

On Mon, Sep 22, 2003 at 09:43:18AM -0500, Grant Edwards wrote:
> 
> Whats the recommended way to keep a 2.0 source tree up to date
> with bug fixes?
> 
> Do I need to try to get BOFH to allow access to the CVS tree?
> 
> Is there an official archive of approved patches somewhere that
> can be downloaded?

eCos does not use the linux model of a stable version and a
development version. 2.0 is static, will not change etc. All patches
are added to the head of the anoncvs tree. We try to keep that bug
free as possible, but there is always the risk that some patch will
break something. You can take a snapshot of the cvs, then run all the
test cases yourself in what ever configuration you need. If it passes,
its probably useable. If it fails, we would like to know!

If you want a certified release which has had extensive testing like
2.0 had, you need to contact the commercial support people. 

    Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Grant Edwards]

On Mon, Sep 22, 2003 at 05:17:46PM +0200, Andrew Lunn wrote:

>> Whats the recommended way to keep a 2.0 source tree up to date
>> with bug fixes?

I guess the answer is "there isn't one".  Once you decide to
use an "official" snapshot, you're more-or-less stuck.

>> Do I need to try to get BOFH to allow access to the CVS tree?

I've been trying to figure out how to use cvs to do something
useful, and I'm stumped.  Since the latest "official" source
tree has all of the directories renamed (2.0 vs. current),
there doesn't seem to be any way for me to use cvs to compare
my ecos-2.0 source tree with the "head".

>> Is there an official archive of approved patches somewhere that
>> can be downloaded?

Apparently no.

> eCos does not use the linux model of a stable version and a
> development version.

Nor does it appear to use the "cvs" model. Since the 2.0
directory structure doesn't match the CVS database, I can't
figure out how to use cvs to find out what's changed either.

> If you want a certified release which has had extensive testing
> like 2.0 had, you need to contact the commercial support
> people.

No, what I want is an automated way to find out what's changed
since 2.0.  If I knew it would be useful, I could probably
argue BOFH into allowing access to the CVS server.

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Gary Thomas]

On Mon, 2003-09-22 at 12:58, Grant Edwards wrote:
> On Mon, Sep 22, 2003 at 05:17:46PM +0200, Andrew Lunn wrote:
> 
> >> Whats the recommended way to keep a 2.0 source tree up to date
> >> with bug fixes?
> 
> I guess the answer is "there isn't one".  Once you decide to
> use an "official" snapshot, you're more-or-less stuck.
> 
> >> Do I need to try to get BOFH to allow access to the CVS tree?
> 
> I've been trying to figure out how to use cvs to do something
> useful, and I'm stumped.  Since the latest "official" source
> tree has all of the directories renamed (2.0 vs. current),
> there doesn't seem to be any way for me to use cvs to compare
> my ecos-2.0 source tree with the "head".
> 

Sadly this naming convention does make using CVS difficult.

> >> Is there an official archive of approved patches somewhere that
> >> can be downloaded?
> 
> Apparently no.
> 
> > eCos does not use the linux model of a stable version and a
> > development version.
> 
> Nor does it appear to use the "cvs" model. Since the 2.0
> directory structure doesn't match the CVS database, I can't
> figure out how to use cvs to find out what's changed either.
> 

That's only true for the release branches.  In general, we do all
of our work against "current" which is exactly the CVS trunk.

> > If you want a certified release which has had extensive testing
> > like 2.0 had, you need to contact the commercial support
> > people.
> 
> No, what I want is an automated way to find out what's changed
> since 2.0.  If I knew it would be useful, I could probably
> argue BOFH into allowing access to the CVS server.
> 

One way to get this is to generate diffs (on the CVS trunk) using
the release tag, e.g.
  cvs diff -r ecos-v2_0-release

If you can't use CVS though, you're rather stuck.  

Note: I've done this just today (to test the theory) and can make
the patches available on my website.  Try:
  http://www.mlbassoc.com/ecos_patches/diffs-2003-09-22.gz
If this is useful to the community, I can automate this and post
the diffs, probably once a week.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Grant Edwards]

>> No, what I want is an automated way to find out what's changed
>> since 2.0.  If I knew it would be useful, I could probably
>> argue BOFH into allowing access to the CVS server.
> 
> One way to get this is to generate diffs (on the CVS trunk) using
> the release tag, e.g.
>
>   cvs diff -r ecos-v2_0-release

Ah. That's what I was looking for.  I was hoping to do it from
my ecos-2.0 tree, but that just isn't going to work.  It looks
like the best option is to "co" a CVS "current" tree and do the
diffs there.

> If you can't use CVS though, you're rather stuck.  

Through the miracle of ssh port-forwarding, I do have cvs
working now -- don't tell BOFH.  Though it's a bit inconvenient
if I want to deal with more than a single outside CVS server.

> Note: I've done this just today (to test the theory) and can make
> the patches available on my website.  Try:
>   http://www.mlbassoc.com/ecos_patches/diffs-2003-09-22.gz
> If this is useful to the community, I can automate this and post
> the diffs, probably once a week.

Thanks for the offer, but now that I have cvs working I think I
can generate the info I'm looking for.  I just need to decide
whether to build product from the ecos-2.0 tree with selected
updates (which means it's not really 2.0), or from the
"current" tree (which means I've got to figure out how to
control updates).

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Gary Thomas]

On Mon, 2003-09-22 at 13:19, Grant Edwards wrote:
> >> No, what I want is an automated way to find out what's changed
> >> since 2.0.  If I knew it would be useful, I could probably
> >> argue BOFH into allowing access to the CVS server.
> > 
> > One way to get this is to generate diffs (on the CVS trunk) using
> > the release tag, e.g.
> >
> >   cvs diff -r ecos-v2_0-release
> 
> Ah. That's what I was looking for.  I was hoping to do it from
> my ecos-2.0 tree, but that just isn't going to work.  It looks
> like the best option is to "co" a CVS "current" tree and do the
> diffs there.
> 
> > If you can't use CVS though, you're rather stuck.  
> 
> Through the miracle of ssh port-forwarding, I do have cvs
> working now -- don't tell BOFH.  Though it's a bit inconvenient
> if I want to deal with more than a single outside CVS server.
> 
> > Note: I've done this just today (to test the theory) and can make
> > the patches available on my website.  Try:
> >   http://www.mlbassoc.com/ecos_patches/diffs-2003-09-22.gz
> > If this is useful to the community, I can automate this and post
> > the diffs, probably once a week.
> 
> Thanks for the offer, but now that I have cvs working I think I
> can generate the info I'm looking for.  I just need to decide
> whether to build product from the ecos-2.0 tree with selected
> updates (which means it's not really 2.0), or from the
> "current" tree (which means I've got to figure out how to
> control updates).

What I do is have my own CVS server (repository).  Then, at certain
times such as starting a new project, I merge the public CVS to the
trunk of my local tree.  I then tag it and work from there - all local.
That way, I have an exact copy of the public tree I started from, as
well as any changes I needed to make for the project.  If/when it makes
sense, I can then also push my local changes back to the public tree.

CVS handles this quite well.  What you have to be familiar with are
the two styles of tags - normal tags and branch tags.  When I'm starting
the project, I add one of each to the head revision.  For example:
  % cvs tag grant-test-branchpoint
  % cvs tag -b grant-test-branch
Then, to work on that project, I need to check out from the branch:
  % cvs co -r grant-test-branch ecos
All changes, new files, etc, are all then made on the branch.  When
I'm ready to see what I've changed - globally since the project began,
I do:
  % cvs diff -r grant-test-branchpoint
I would then merge this (probably with a little hand effort) to the
public tree.  I'm currently using this technique for working on both
eCos and Linux, and it helps me keep very good tabs on projects that
may diverge quite radically from the public sources.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Grant Edwards]

On Mon, Sep 22, 2003 at 01:29:28PM -0600, Gary Thomas wrote:

> What I do is have my own CVS server (repository).  Then, at
> certain times such as starting a new project, I merge the
> public CVS to the trunk of my local tree.  I then tag it and
> work from there - all local. That way, I have an exact copy of
> the public tree I started from, as well as any changes I needed
> to make for the project.  If/when it makes sense, I can then
> also push my local changes back to the public tree.

That's definitely the right way to do it.  I've just been
reading up on CVS "vendor" tags" which appear to be designed
for just such situations.  

Unfortunately, I'd still have to use MS VSS as well as local a
CVS repository, but that's another issue.

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Reinhard JESSICH]

>>> Grant Edwards <grante@visi.com> 09/22/03 09:34pm >>>
> On Mon, Sep 22, 2003 at 01:29:28PM -0600, Gary Thomas wrote:
> > What I do is have my own CVS server (repository).  Then, at
> > certain times such as starting a new project, I merge the
> > public CVS to the trunk of my local tree.  I then tag it and
> > work from there - all local. That way, I have an exact copy of
> > the public tree I started from, as well as any changes I needed
> > to make for the project.  If/when it makes sense, I can then
> > also push my local changes back to the public tree.

> That's definitely the right way to do it.  I've just been
> reading up on CVS "vendor" tags" which appear to be designed
> for just such situations.

I would *not suggest* using the vendor branch feature of CVS directly on the main branch,
as you might end up with an inconsistent state (at least temporarily).

Here is what we are doing:

We checked out a local copy from the annon CVS. Then we imported
it to our CVS main branch with the "cvs import" command. After that we created a branch
and started our own developments on this branch.

We have a cron job running, which will update the local copy of the annon CVS weekly and
generate a diff report about the ChangeLog files. This report is checked by the developers
and if there is an interesting change, we import from the local copy of the annon CVS to our
main branch "cvs import vendor-tag release-tag". We do this at least once in two months,
to keep track of the ongoing development.

As a final step we incorporate the changes on the main branch (same as annon CVS) into
our development branch. This is now very simple. Use:
"cvs update -j last-release -j new-release". This command will update our development with
only those changes, which were made between the two releases. last-release and new-release
are the release tags which were defined with "cvs import".

Note, that it is important to work on an development branch, because the "cvs import"
command automatically merges and commits. If you work directly on the main
branch you are not really happy about this (I know it from experience).

BR
   Reinhard

-- 
 Ing. Reinhard Jessich                Phone: +43/1/81150/2395
 Software Design                      Fax: +43/1/81150/3169
 Frequentis Nachrichtentechnik GmbH   A-1120 Wien, Spittelbreitengasse 34
 http://www.frequentis.com            eMail: reinhard.jessich@frequentis.com


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Roland Caßebohm]

On Dienstag, 23. September 2003 13:03, Reinhard JESSICH wrote:
> I would *not suggest* using the vendor branch feature of CVS directly on
> the main branch, as you might end up with an inconsistent state (at least
> temporarily).
>
> Here is what we are doing:
>
> We checked out a local copy from the annon CVS. Then we imported
> it to our CVS main branch with the "cvs import" command. After that we
> created a branch and started our own developments on this branch.
>
> We have a cron job running, which will update the local copy of the annon
> CVS weekly and generate a diff report about the ChangeLog files. This
> report is checked by the developers and if there is an interesting change,
> we import from the local copy of the annon CVS to our main branch "cvs
> import vendor-tag release-tag". We do this at least once in two months, to
> keep track of the ongoing development.

Is vendor-tag everytime the same, or do I have to rename it everytime I call
cvs import?
With release-tag I will do somthing like release-yyyy_mm_dd, but I'm not 
sure what to do with the vendor-tag.

Thank you,
Roland

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[David Vrabel]

[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]

[Oops.  Sent this too the wrong list.]

Reinhard JESSICH wrote:
>
> I would *not suggest* using the vendor branch feature of CVS directly on the main branch,
> as you might end up with an inconsistent state (at least temporarily).
> 
> Here is what we are doing:
> 
> We checked out a local copy from the annon CVS. Then we imported
> it to our CVS main branch with the "cvs import" command. After that we created a branch
> and started our own developments on this branch.
> 
> We have a cron job running, which will update the local copy of the annon CVS weekly and
> generate a diff report about the ChangeLog files. This report is checked by the developers
> and if there is an interesting change, we import from the local copy of the annon CVS to our
> main branch "cvs import vendor-tag release-tag". We do this at least once in two months,
> to keep track of the ongoing development.
> 
> As a final step we incorporate the changes on the main branch (same as annon CVS) into
> our development branch. This is now very simple. Use:
> "cvs update -j last-release -j new-release". This command will update our development with
> only those changes, which were made between the two releases. last-release and new-release
> are the release tags which were defined with "cvs import".
> 
> Note, that it is important to work on an development branch, because the "cvs import"
> command automatically merges and commits. If you work directly on the main
> branch you are not really happy about this (I know it from experience).

Er.  This sounds like using a vendor branch only you're using the main
branch as the vendor branch and your development branch as the main branch.

FWIW, find two scripts attached that we use.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom                         Tel: +44 (0)1223 411200 ext. 3233
Clifton Road                  Fax: +44 (0)1223 403400
Cambridge CB1 7EA             E-mail: dvrabel@arcom.com
UK                            Web: http://www.arcom.com/


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

[-- Attachment #2: edk-ecos-commit-merge --]
[-- Type: text/plain, Size: 800 bytes --]

#! /bin/sh
# edk-ecos-commit-merge -- commits the latest merge of upstream eCos with
# the local ecos repository.
#
# Instructions:
# 1. Run
#    $ edk-ecos-import-upstream <directory>
# 2. Manually fix conflicts in <directory>/ecos-merged
# 3. Run
#    $ edk-ecos-import-upstream <directory>

set -e

if [ -z "$1" ]; then
    echo "Usage:"
    echo "  $(basename $0) <directory>"
    exit 1
fi

TOPDIR=$1

LATEST_IMPORT_TAG=ECOS_LATEST_IMPORT
TAG_DATE=$(date "+%Y%m%d")
HUMAN_DATE=$(date)

if [ ! -d ${TOPDIR}/ecos-merged ]; then
    echo "$(basename $0): \`${TOPDIR}' doesn't contain the merged ecos tree"
    exit 1
fi

cd ${TOPDIR}/ecos-merged
cvs commit -m "Merged from upstream CVS (${HUMAN_DATE})."

# Move the ECOS_LATEST_IMPORT tag
cvs rtag -F -r ECOS_${TAG_DATE} ${LATEST_IMPORT_TAG} ecos


[-- Attachment #3: edk-ecos-import-upstream --]
[-- Type: text/plain, Size: 1174 bytes --]

#! /bin/sh
# edk-ecos-import-upstream -- imports the latest eCos from upstream CVS into
# the local ecos repository.
#
# Instructions:
# 1. Run
#    $ edk-ecos-import-upstream <directory>
# 2. Manually fix conflicts in <directory>/ecos-merged
# 3. Run
#    $ edk-ecos-import-upstream <directory>


set -e

if [ -z "$1" ]; then
    echo "Usage:"
    echo "  $(basename $0) <directory>"
    exit 1
fi

TOPDIR=$1

LATEST_IMPORT_TAG=ECOS_LATEST_IMPORT
TAG_DATE=$(date "+%Y%m%d")
HUMAN_DATE=$(date)

if [ -e ${TOPDIR}/ecos -o -e ${TOPDIR}/ecos-merged ]; then
    echo "$(basename $0): \`${TOPDIR}' contains a possible ecos repository already"
    exit 1
fi

# Grab the latest eCos upstream...
cd $TOPDIR
cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/ecos login
cvs -z3 -d :pserver:anoncvs@sources.redhat.com:/cvs/ecos co -P ecos
cd ecos
find -type d -a -name CVS |  xargs rm -r
cvs import -m "Imported from upstream CVS (${HUMAN_DATE})." ecos upstream ECOS_${TAG_DATE}

cd $TOPDIR
cvs co -j$LATEST_IMPORT_TAG -jECOS_${TAG_DATE} -d ecos-merged ecos

echo -e "\n*\n* Manually fix conflicts in \`${TOPDIR}/ecos-merged'.\n*\n"
echo "Then run \`edk-ecos-commit-merge ${TOPDIR}'."



[-- Attachment #4: Type: text/plain, Size: 146 bytes --]

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Roland Caßebohm]

On Montag, 29. September 2003 18:32, Reinhard JESSICH wrote:
> >>> Roland Caßebohm <roland.cassebohm@visionsystems.de> 09/29/03 05:50pm
> >>> >>>
>
> <snip>
>
> > > we import from the local copy of the annon CVS to our main branch "cvs
> > > import vendor-tag release-tag". We do this at least once in two months,
> > > to keep track of the ongoing development.
> >
> > Is vendor-tag everytime the same, or do I have to rename it everytime I
> > call cvs import?
> > With release-tag I will do somthing like release-yyyy_mm_dd, but I'm not
> > sure what to do with the vendor-tag.
>
> The vendor-tag have to be the same for several imports.
> We use "ecos-2-0-repo" and "ecos-ddmmyy" for the release-tag.
> If there will be an ecos-3.0 version in the future, we will use
> "ecos-3-0-repo" as vendor-tag. But then we have to import it to an other
> branch. So you will need the -b option for cvs import. cvs import uses -b
> 1.1.1 as the default. If you will not use -b 1.1.2 for the new branch, cvs
> will import it to the 1.1.1 branch, which is "ecos-2-0-repo". Using -b is
> necessary, because cvs doesn't use the vendor-tag to find the right branch.

Thank you, it is a little bit clearer now for me :-)

Best regards,
Roland

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Keeping 2.0 source tree up to date

[Reinhard JESSICH]

>>> Roland Caßebohm <roland.cassebohm@visionsystems.de> 09/29/03 05:50pm >>>

<snip>

> > we import from the local copy of the annon CVS to our main branch "cvs
> > import vendor-tag release-tag". We do this at least once in two months, to
> > keep track of the ongoing development.

> Is vendor-tag everytime the same, or do I have to rename it everytime I call
> cvs import?
> With release-tag I will do somthing like release-yyyy_mm_dd, but I'm not 
> sure what to do with the vendor-tag.

The vendor-tag have to be the same for several imports.
We use "ecos-2-0-repo" and "ecos-ddmmyy" for the release-tag.
If there will be an ecos-3.0 version in the future, we will use "ecos-3-0-repo" as
vendor-tag. But then we have to import it to an other branch. So you will need the
-b option for cvs import. cvs import uses -b 1.1.1 as the default. If you will not use
-b 1.1.2 for the new branch, cvs will import it to the 1.1.1 branch, which is
"ecos-2-0-repo". Using -b is necessary, because cvs doesn't use the vendor-tag to find the
right branch.

BR
   Reinhard


-- 
 Ing. Reinhard Jessich                Phone: +43/1/81150/2395
 Software Design                      Fax: +43/1/81150/3169
 Frequentis Nachrichtentechnik GmbH   A-1120 Wien, Spittelbreitengasse 34
 http://www.frequentis.com            eMail: reinhard.jessich@frequentis.com


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss