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

[Gary Thomas <gary at mlbassoc dot com>]

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