Re: Direct CVS Access to egcs sources

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message <199801231742.JAA01350@cygnus.com>you write:
  > Forget my request and use the cvs2html tool (perl script)
  > < http://eivind.imm.dtu.dk/cvs2html/ > mentioned by Robert Lipe, it's great!!
  > Started daily it will produce HTML files via "cvs log" and it is really
  > easy to setup.
Noted.

  > BTW, is there any way to speedup the egcs mailing list? It's so SLOOOOWW!
We're working on it.

jeff

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message <19980209020929.50632@cerebro.laendle>you write:
  > > 
  > > One of the things on my long term todo list is to find the few remaining
  > > keywords in egcs and kill them.
  > 
  > Start with these, I really hate them, because it's thes
Actually I was thinking about turning off expansion via CVS; no editing
necessary, run the magic command at the toplevel egcs directory and
the expansion will just stop.

Thoughts anyone?  Does anyone actually care about the RCS keyword
expansions?

jeff

Re: Direct CVS Access to egcs sources

[Joern Rennecke]

> Thoughts anyone?  Does anyone actually care about the RCS keyword
> expansions?

I routinely check out with -ko to avoid spurious diffs...

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message < 199802100001.AAA20538@phal.cygnus.co.uk >you write:
  > > Thoughts anyone?  Does anyone actually care about the RCS keyword
  > > expansions?
  > 
  > I routinely check out with -ko to avoid spurious diffs...
Well, if we turn it off via cvs admin, you wouldn't have to do
that anymore.

The main reason for turning it off is to avoid merging issues;
the other approach is to just delete the RCS keywords from the
effected files.

Jeff

Re: Direct CVS Access to egcs sources

[Marc Lehmann]

On Mon, Feb 09, 1998 at 09:20:08PM -0700, Jeffrey A Law wrote:
> 
>   > I routinely check out with -ko to avoid spurious diffs...
> Well, if we turn it off via cvs admin, you wouldn't have to do
> that anymore.
> 
> The main reason for turning it off is to avoid merging issues;
> the other approach is to just delete the RCS keywords from the
> effected files.

delete them. nobody needs them. please... they carry no useful
information.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message <199801142227.OAA03715@cygnus.com>you write:
  > could you setup a simple webpage which links in all the current ChangeLogs
  > from the cvs tree? Something like:
  > 
  > ChangeLog
  > gcc/ChangeLog
  > libio/ChangeLog
  > etc.
  > 
  > I think this would be quite useful.
Well, I suspect you can get everything you'd need via "cvs log" and its
associated friends.  However, I can see how this could be helpful.

However, until www service is moved it would be non-trivial to keep these
files up-to-date.  We are planning on moving www service to egcs.cygnus.com,
but there's other stuff that's got a higher priority right now.

jeff

Re: Direct CVS Access to egcs sources

[Franz Sirl]

At 07:38 23.01.98 , Jeffrey A Law wrote:
>
>  In message <199801142227.OAA03715@cygnus.com>you write:
>  > could you setup a simple webpage which links in all the current
ChangeLogs
>  > from the cvs tree? Something like:
>  > 
>  > ChangeLog
>  > gcc/ChangeLog
>  > libio/ChangeLog
>  > etc.
>  > 
>  > I think this would be quite useful.
>Well, I suspect you can get everything you'd need via "cvs log" and its
>associated friends.  However, I can see how this could be helpful.
>
>However, until www service is moved it would be non-trivial to keep these
>files up-to-date.  We are planning on moving www service to egcs.cygnus.com,
>but there's other stuff that's got a higher priority right now.

Forget my request and use the cvs2html tool (perl script)
< http://eivind.imm.dtu.dk/cvs2html/ > mentioned by Robert Lipe, it's great!!
Started daily it will produce HTML files via "cvs log" and it is really
easy to setup.

BTW, is there any way to speedup the egcs mailing list? It's so SLOOOOWW!

Bye,
Franz.

Re: Direct CVS Access to egcs sources

[Mike Stump]

> To: egcs@cygnus.com
> From: jhpb@sarto.gaithersburg.md.us (Joseph H. Buehler)
> Date: 17 Jan 1998 18:52:52 -0500

> Jeffrey A Law <law@cygnus.com> writes:

> I am finding that the initial cvs checkout operation is very
> sloooooow.  Could you put up a tar.gz of the tree that the initial
> checkout makes, to get us all going?

That probably won't make it go faster...  :-) Make sure to use the -z
option, to turn on compression, that can make a bit of different I
suspect.

Direct CVS Access to egcs sources

[Jeffrey A Law]

January 12, 1998

In an ongoing effort to accelerate development of egcs and provide an
open development environment, we are making the egcs CVS source repository
available readonly to the public at large.

You'll be able to pick up the latest code whenever you want instead of
waiting for periodic snapshots.  You'll even be able to check out the
release branch(es) since they also live in the CVS repository.

If you don't already have CVS, we recommend you pick up a recent copy from
Cyclic Software at http://www.cyclic.com .

Assuming you have CVS installed on your machine you can check out the egcs
sources with the following sequence of commands:

set CVSROOT in your environment to

:pserver:anoncvs@egcs.cygnus.com:/egcs/carton/cvsfiles 

Or alternately add "-d :pserver:anoncvs@egcs.cygnus.com:/egcs/carton/cvsfiles"
in the CVS commands below (place it immediately after "cvs" -- ie
before any other cvs arguments).

Issue the command "cvs login".  You will be prompted for a password;
reply with "anoncvs".

Issue the command "cvs co egcs" to check out the egcs sources.

Once you've got the repository checked out "cvs update" will sync your
local sources with those in the repository.  See the CVS manual for
additional information on how to use CVS.


Enjoy!

Re: Direct CVS Access to egcs sources

[Oleg Krivosheev]

Hi,

On Mon, 12 Jan 1998, Jeffrey A Law wrote:

> January 12, 1998
> 
> In an ongoing effort to accelerate development of egcs and provide an
> open development environment, we are making the egcs CVS source repository
> available readonly to the public at large.
> 
> You'll be able to pick up the latest code whenever you want instead of
> waiting for periodic snapshots.  You'll even be able to check out the
> release branch(es) since they also live in the CVS repository.

Jeffrey,

how you're going to bump snapshot number/date/location?
Just randomly from time to time?

And what about people doing hard work
testing latest snapshots on different
computer/systems? Looks like it
doesn't make any sense now?

regards

OK

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message < Pine.GSO.3.96.980114101424.691A-100000@drabble.fnal.gov >you write:
  > how you're going to bump snapshot number/date/location?
  > Just randomly from time to time?
Folks have suggested a nightly cron job to bump it.  That's one possibility.

The other is to do it via a weekly cron job for snapshots (which means I'd
have to finish the last 10% of the work necessary to automate snapshots).

Another is to change the date in version.c nightly, but not the version #.

I'm actually open to any one of the these suggestions (or others).  I'd
kinda lean towards the second since that's how Cygnus has worked with
gcc2 snapshots and our repository in the past.  However if folks prefer
something different I'm not going to force any particular scheme on y'all.

  > And what about people doing hard work
  > testing latest snapshots on different
  > computer/systems? Looks like it
  > doesn't make any sense now?
It still makes sense, we're just changing the focus of the distribution of
the source code from snapshots to direct CVS access.

In fact, one of the nice things CVS does for us is you'll be able to
actually check out any given snapshot, or update your sources to any
given snapshot (moving either forward or backward in time!)

cvs co -regcs_ss_yymmdd

Would check out snapshot yymmdd

Or, if you already had a repository and wanted to make it look like
snapshot yymmdd you'd do

cvs update -regcs_ss_yymmdd


This is possible because we tag each snapshot in the repository.


So, what needs to happen:

  1.  I need to get a new snapshot made.  I put this on the back burner
  to get CVS going and due to company commitments.

  2.  Make some decisions about the version # and when to bump it.

  3.  Finish automating the snapshot process so that it happens on at
  regular intervals.


jeff

Re: Direct CVS Access to egcs sources

[Joe Buck]

>   > how you're going to bump snapshot number/date/location?
>   > Just randomly from time to time?
> Folks have suggested a nightly cron job to bump it.  That's one possibility.

If you really want to be able to tell what people are running based
just on the version number, it seems that the version should be updated
each time a non-documentation file is checked in.  Otherwise figuring
out test results is going to get really confusing.

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message < 199801151559.HAA00673@atrus.synopsys.com >you write:
  > 
  > >   > how you're going to bump snapshot number/date/location?
  > >   > Just randomly from time to time?
  > > Folks have suggested a nightly cron job to bump it.  That's one possibili
  > ty.
  > 
  > If you really want to be able to tell what people are running based
  > just on the version number, it seems that the version should be updated
  > each time a non-documentation file is checked in.  Otherwise figuring
  > out test results is going to get really confusing.
That's another option.  CVS has this kind of capability.

It might be overkill, then again it might not.  That's why I'm asking
for opinions :-)

jeff

Re: Direct CVS Access to egcs sources

[Joe Buck]

I wrote:
>   > If you really want to be able to tell what people are running based
>   > just on the version number, it seems that the version should be updated
>   > each time a non-documentation file is checked in.  Otherwise figuring
>   > out test results is going to get really confusing.



> That's another option.  CVS has this kind of capability.

Then please do it.

> It might be overkill, then again it might not.  That's why I'm asking
> for opinions :-)

I think that it will have a huge advantage.  Let's say two people send in
test reports for the same platform, with the same version, and one has an
additional failure.  With cron-generated timestamps, you'll have to search
through a whole day's changes to figure out if some patch caused the
failure.  With an update-on-every-checkin version, you know they are
running identical code and you can start looking for subtle system
differences.

You could lessen the problem by doing a new version string every hour,
say, but then people may have identical software that differs only in
a version number.

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message <199801151801.KAA03652@atrus.synopsys.com>you write:
  > I think that it will have a huge advantage.  Let's say two people send in
  > test reports for the same platform, with the same version, and one has an
  > additional failure.  With cron-generated timestamps, you'll have to search
  > through a whole day's changes to figure out if some patch caused the
  > failure.  With an update-on-every-checkin version, you know they are
  > running identical code and you can start looking for subtle system
  > differences.
  > 
  > You could lessen the problem by doing a new version string every hour,
  > say, but then people may have identical software that differs only in
  >
  > a version number.
How about we continue to bump the version # for snapshots, but change
the "date" string via a nightly cron job?

I just don't see the need at this point to bump the version # at each
checkin -- that (of course) can change if we have a difficult time
interpreting test results.

Does this sound reasonable?


jeff

Re: Direct CVS Access to egcs sources

[Gerald Pfeifer]

On Sun, 8 Feb 1998, Jeffrey A Law wrote:
> How about we continue to bump the version # for snapshots, but change
> the "date" string via a nightly cron job?

Yes, please do that.

If it does not prove sufficient, we can always change to an even finer
grained version labeling later. The daily change defintely will be useful. 

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Direct CVS Access to egcs sources

[Dave Love]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

 Gerald> On Sun, 8 Feb 1998, Jeffrey A Law wrote:
 >> How about we continue to bump the version # for snapshots, but change
 >> the "date" string via a nightly cron job?

 Gerald> Yes, please do that.

 Gerald> If it does not prove sufficient, we can always change to an
 Gerald> even finer grained version labeling later. The daily change
 Gerald> defintely will be useful.

Why isn't the usual `ident' mechanism appropriate, given you can't
guarantee the integrity of a given set of sources, even WRT a given
date?  Do the potentially-annoying problems with patches swing it or
something else?

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message < rzq90rmhw5n.fsf@djlvig.dl.ac.uk >you write:
  > Why isn't the usual `ident' mechanism appropriate, given you can't
  > guarantee the integrity of a given set of sources, even WRT a given
  > date?  Do the potentially-annoying problems with patches swing it or
  > something else?
RCS keyword expansion is a pain to deal with when merging in changes from
multiple source trees.

One of the things on my long term todo list is to find the few remaining
keywords in egcs and kill them.

jeff

Re: Direct CVS Access to egcs sources

[H.J. Lu]

> How about we continue to bump the version # for snapshots, but change
> the "date" string via a nightly cron job?
> 
> I just don't see the need at this point to bump the version # at each
> checkin -- that (of course) can change if we have a difficult time
> interpreting test results.
> 
> Does this sound reasonable?
> 

Can we bump the version # if there is any change as well as
the "date" string everyday? It can be done via a nightly cron job.

-- 
H.J. Lu (hjl@gnu.org)

Re: Direct CVS Access to egcs sources

[Bryan W. Headley]

On Feb 8,  1:22pm, H.J. Lu wrote:
> Subject: Re: Direct CVS Access to egcs sources
> > How about we continue to bump the version # for snapshots, but change
> > the "date" string via a nightly cron job?
> >
> > I just don't see the need at this point to bump the version # at each
> > checkin -- that (of course) can change if we have a difficult time
> > interpreting test results.
> >
> > Does this sound reasonable?
> >
>
> Can we bump the version # if there is any change as well as
> the "date" string everyday? It can be done via a nightly cron job.
>
The old sccs_id? That's broken too, because the thing expands out while
you have the file checked out. What you have to do is have something like this:

/* sccs_id="bozo.c 1.00.5.6 2/8/1998 (this put in by cron process) */
static const char * sccs_id="%W% %G% etc.";

The line above the sccs_id is expanded out as a comment by cron, so the version
the file has when you opened it is still apparant.

>-- End of excerpt from H.J. Lu

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message < m0y1eB7-0004ecC@ocean.lucon.org >you write:
  > > How about we continue to bump the version # for snapshots, but change
  > > the "date" string via a nightly cron job?
  > > 
  > > I just don't see the need at this point to bump the version # at each
  > > checkin -- that (of course) can change if we have a difficult time
  > > interpreting test results.
  > > 
  > > Does this sound reasonable?
  > > 
  > 
  > Can we bump the version # if there is any change as well as
  > the "date" string everyday? It can be done via a nightly cron job.
That just seems like overkill at this time.  It's not clear that we
need the version # to change every time.

And the cost of doing that is noticable -- we would have had over 700
versions by now, and each and every one that you built and installed
would have gone into its own install directory.

I just haven't seen that much ambiguity in bug reports and such that
leads me to believe that we need to bump the version # for each checkin.
If we do see lots of problems of this nature, then changing the version
number more rapidly would make sense.

jeff

Re: Direct CVS Access to egcs sources

[H.J. Lu]

>   > 
>   > Can we bump the version # if there is any change as well as
>   > the "date" string everyday? It can be done via a nightly cron job.
> That just seems like overkill at this time.  It's not clear that we
> need the version # to change every time.
> 
> And the cost of doing that is noticable -- we would have had over 700

When did egcs start? If one version is generated per day, it
should be less than 700. If there is any change made to egcs/gcc,
egcs-2.x.y 98mmdd is updated to egcs-2.x.y+1 98mmdd.

> versions by now, and each and every one that you built and installed
> would have gone into its own install directory.

That is what I want. I can easily remove those. But I may not
want to override the previous one. It helps track down the new
bug when it appears.



-- 
H.J. Lu (hjl@gnu.org)

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message < m0y1g1b-0004ecC@ocean.lucon.org >you write:
  > >   > 
  > >   > Can we bump the version # if there is any change as well as
  > >   > the "date" string everyday? It can be done via a nightly cron job.
  > > That just seems like overkill at this time.  It's not clear that we
  > > need the version # to change every time.
  > > 
  > > And the cost of doing that is noticable -- we would have had over 700
  > 
  > When did egcs start? If one version is generated per day, it
  > should be less than 700. If there is any change made to egcs/gcc,
  > egcs-2.x.y 98mmdd is updated to egcs-2.x.y+1 98mmdd.
Sorry, I mis-understood, I thought you meant on each checkin.

  > > versions by now, and each and every one that you built and installed
  > > would have gone into its own install directory.
  > 
  > That is what I want. I can easily remove those. But I may not
  > want to override the previous one. It helps track down the new
  > bug when it appears.
But it's not clear if that's what the rest of the folks here want; we've
had a couple for and a couple against.

How about this -- we'll ask folks to vote.  I'm willing to abide by
whatever decision the group makes on this subject.

Say we close the voting on Feb 28th?

Options:


  a. Version # updated for every checkin, date in version string updated
  nightly.

  b. Version # and date in version string updated nightly.

  c. Version # updated for snaphots, date in version string updated nightly

  d. Version # and date updated for snapshots

  e. Write in candidates.


Anyone want to tabulate votes?  Basically keep track of who voted and what
selection they voted for.  If nobody else wants to, I'll do it (or better
yet, someone want to dontate web expertise to have it do these things for
us?

jeff




  


  > 
  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)

Re: Direct CVS Access to egcs sources

[Todd Vierling]

On Sun, 8 Feb 1998, Jeffrey A Law wrote:

:   > That is what I want. I can easily remove those. But I may not
:   > want to override the previous one. It helps track down the new
:   > bug when it appears.
: But it's not clear if that's what the rest of the folks here want; we've
: had a couple for and a couple against.

:   d. Version # and date updated for snapshots

This is my vote (which is already done, right?)--because it actually is
manageable.

What we need more than tipping up the date every night is for a little
tutorial on using CVS and its various included commands, `diff' in
particular. 

If I read the thread correctly, this is all about making sure that we know
what revision of a file goes with a user supplied patch.  If we get people,
who are using CVS instead of downloading tarfiles of snapshots or releases,
to properly do `cvs diff', the revisions of files in a patch should be
obvious from the cvs diff output.  If the people in question are using
downloaded tarfiles, the revisions are obvious (they have a given
-regcs_ss_?????? tag). 

Now, did I miss something big?  Probably, but oh well--ignore me if so.  :)

=====
===== Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)
== "There's a myth that there is a scarcity of justice to go around, so
== that if we extend justice to 'those people,' it will somehow erode the
== quality of justice everyone else receives."  -- Maria Price

Re: Direct CVS Access to egcs sources

[Raja R Harinath]

Joe Buck <jbuck@synopsys.com> writes:
> >   > how you're going to bump snapshot number/date/location?
> >   > Just randomly from time to time?
> > Folks have suggested a nightly cron job to bump it.  That's one possibility
> 
> If you really want to be able to tell what people are running based
> just on the version number, it seems that the version should be updated
> each time a non-documentation file is checked in.  Otherwise figuring
> out test results is going to get really confusing.

Jeff Law mentioned that every snapshot is tagged something like
egcs_ss_YYYYMMDD.  If so, the testers could be asked to use a specific
tag when they do the cvs update.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: Direct CVS Access to egcs sources

[Robert Lipe]

I have nothing to say in the official egcs policy on this topic.
I do have an understanding of how CVS can help glue a geographically
challenged team together.

Oleg Krivosheev wrote:

> how you're going to bump snapshot number/date/location?
> Just randomly from time to time?

Since not everyone will have CVS access, (much of the world is
still UUCP connected, for example) it's my understanding
that snapshots will still be made.  Even if everyone *did* have 
CVS access, not everyone will want to track things that closely.

We do need some way to distinguish the CVS snapshots of any given
moment in time.

> And what about people doing hard work testing latest snapshots on different
> computer/systems? Looks like it doesn't make any sense now?

I must not understand the concern.   It still make perfect sense 
for things to be tested on a wide variety of hardware.


Now people have a choice.   If they're CVS enabled (and internet 
connected) and can crank out an update/build/test each hour, they 
can find out *exactly* when something broke or began working.  (If 
you're actually in that category, perhaps getting outside once in a 
while would do you some good. :-)  If they're  not, they can wait for 
the announcement of the snaps and grab them as always.  Of course, 
if they are CVS enabled and just choose not to track the release of 
the moment, they can still use CVS to get to the snapshots via the
tags that are applied as part of the snapshot process.

Having CVS access also allows us to work out patch integration 
issues in a way that we know they'll apply cleanly to the master
sources, making the lives of those with actual write access to the
master repository easier.

There is no more waiting for someone to submit a patch to the list
for CVS users.  When someone reports, "Yeah, I committed that last 
week in dwarf2out.c and reload.c", we can type 'cvs update dwarf2out.c 
reload.c' and inherit those fixes without nuking everything else
and without the developer making an explicit patch.

CVS users can also do our testing on different computers/systems 
when it's best for them instead of trying to synchronize it to the times
when snaps are made available.   I know the backup cycles on my machine 
and when my WAN is most idle.  I know when I have the most clock cycles
available. (hint: usually I'm in bed) Now I can target test cycles 
to those times instead of waiting for the next one of those times 
after Jeff's insomnia acts up and he happens to make a snapshot. ;-)

Target-specific bugs can be implemented, detected, and corrected
in a shorter time frame than a previous snapshot cycle.

When I totally go off on a rant and do something Really Bad to my
local copy of the sources, it's just a matter of 'cvs status' to see
which files we've hosed and a matter of nuking them and a 'cvs update'
to refresh them.  



We have lots of choices and options available to us now.   If you 
want to stay with the snapshot/patch model, I understand that'll 
still be available.

I welcome the options that immediate EGCS repository access gives 
me.  If EGCS was previously the bazaar, we now have the option of 
a traditional bazaar/flea market or a "speed" auction with very 
fast turnaround cycles and the ability to bid when we're not even 
in the room, but more when it's convenient for us.

I like it.

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message < 19980115012422.08714@dgii.com >you write:
  > Since not everyone will have CVS access, (much of the world is
  > still UUCP connected, for example) it's my understanding
  > that snapshots will still be made.  Even if everyone *did* have 
  > CVS access, not everyone will want to track things that closely.
Right.


  > We do need some way to distinguish the CVS snapshots of any given
  > moment in time.
Absolutely.

The question is how fine grained to we want to be able to distinguish
a checked out tree.  Daily?  Every check-in?  No decision has been
made, so further comments/suggestions are welcome.

  > Now people have a choice.   If they're CVS enabled (and internet 
  > connected) and can crank out an update/build/test each hour, they 
  > can find out *exactly* when something broke or began working.  (If 
  > you're actually in that category, perhaps getting outside once in a 
  > while would do you some good. :-)  If they're  not, they can wait for 
  > the announcement of the snaps and grab them as always.  Of course, 
  > if they are CVS enabled and just choose not to track the release of 
  > the moment, they can still use CVS to get to the snapshots via the
  > tags that are applied as part of the snapshot process.
Yup.

  > Having CVS access also allows us to work out patch integration 
  > issues in a way that we know they'll apply cleanly to the master
  > sources, making the lives of those with actual write access to the
  > master repository easier.
CVS access also makes is easier on those developing patches -- unless
there's a conflict with a change made in the repository CVS will
automatically merge in changes from the repository with your local changes.

If there's a conflict it will be clearly marked and you get to go fix
it :-)

[ More cool things about CVS removed... ]

  > We have lots of choices and options available to us now.   If you 
  > want to stay with the snapshot/patch model, I understand that'll 
  > still be available.
Absolutely.  The plan is to finish the last 10% of the snapshot script
so that it can run automatically at a preset time every week.  Unfortunately
I'll be on the road again most of next week, so it might be a couple weeks
before I sit down to finish things up.

jeff

Re: Direct CVS Access to egcs sources

[Franz Sirl]

Hi,

could you setup a simple webpage which links in all the current ChangeLogs
from the cvs tree? Something like:

ChangeLog
gcc/ChangeLog
libio/ChangeLog
etc.

I think this would be quite useful.

Bye,
Franz.

At 06:54 13.01.98 , Jeffrey A Law wrote:
>
>January 12, 1998
>
>In an ongoing effort to accelerate development of egcs and provide an
>open development environment, we are making the egcs CVS source repository
>available readonly to the public at large.
>
>You'll be able to pick up the latest code whenever you want instead of
>waiting for periodic snapshots.  You'll even be able to check out the
>release branch(es) since they also live in the CVS repository.
>
>If you don't already have CVS, we recommend you pick up a recent copy from
>Cyclic Software at http://www.cyclic.com .
>
>Assuming you have CVS installed on your machine you can check out the egcs
>sources with the following sequence of commands:
>
>set CVSROOT in your environment to
>
>:pserver:anoncvs@egcs.cygnus.com:/egcs/carton/cvsfiles 
>
>Or alternately add "-d
:pserver:anoncvs@egcs.cygnus.com:/egcs/carton/cvsfiles"
>in the CVS commands below (place it immediately after "cvs" -- ie
>before any other cvs arguments).
>
>Issue the command "cvs login".  You will be prompted for a password;
>reply with "anoncvs".
>
>Issue the command "cvs co egcs" to check out the egcs sources.
>
>Once you've got the repository checked out "cvs update" will sync your
>local sources with those in the repository.  See the CVS manual for
>additional information on how to use CVS.
>
>
>Enjoy!
> 

Re: Direct CVS Access to egcs sources

[Robert Lipe]

> could you setup a simple webpage which links in all the current ChangeLogs
> from the cvs tree? Something like:
> 
> ChangeLog
> gcc/ChangeLog
> libio/ChangeLog
> etc.

Actually, if you have CVS access, that may be less interesting than 
you think.   (But potentially still useful.) Since the CVS logs from 
those files essentially *are* those files, I've found that:
	cvs log gcc/ChangeLog | paging filter of your choosing
is quite handy in telling me if I want to bother with an update/build/test
before I even start it.

For example:
(robertl) rjlhome:/play/egcs/gcc
$ cvs status ChangeLog
===================================================================
File: ChangeLog         Status: Needs Patch

   Working revision:    1.604
   Repository revision: 1.609   /egcs/carton/cvsfiles/egcs/gcc/ChangeLog,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)


This tells me the last time I refreshed, gcc's ChangeLog was at 
version 1.604.   The last checked in versino is 1.609.   When I 
do the 'cvs log', I can see the changes made since 1.604 and decide
if I want to refresh or not.



Now, with that said, if you want automated ChangeLog entries, there
is a decent tool to do it.   Look at
	http://eivind.imm.dtu.dk/cvs2html/
It's easy enough to invoke either via a cron job or via th ecvs loginfo
mechanisms.

Re: Direct CVS Access to egcs sources

[Joseph H. Buehler]

Jeffrey A Law <law@cygnus.com> writes:

> In an ongoing effort to accelerate development of egcs and provide an
> open development environment, we are making the egcs CVS source repository
> available readonly to the public at large.

I am finding that the initial cvs checkout operation is very
sloooooow.  Could you put up a tar.gz of the tree that the initial
checkout makes, to get us all going?

Joe Buehler

Re: Direct CVS Access to egcs sources

[Robert Lipe]

Joseph H. Buehler wrote:

> I am finding that the initial cvs checkout operation is very
> sloooooow.  Could you put up a tar.gz of the tree that the initial

I'm going to try avoiding making this into the CVS discussion list, 
but will try to offer the minimal amount of information to help others
on this list be productive with CVS.

Current CVS has the ability to compress (gzip) the bytestream that flows
over the wire.   For program source (which is, of course, what we're 
interested in here) this can be a substantial optimization in the number
of bytes flowing over the wire.  Remote CVS speed - especially over a 
WAN - can be helped substantially by including "-z9" on the CVS checkout
command.   Better yet, stick it in your ~/.cvsrc and never think about it
again.   Here's mine to get you started looking in cvs.texinfo:

$ cat ~/.cvsrc
diff -u -p
cvs -z9 -q

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com

Re: Direct CVS Access to egcs sources

[Fred Fish]

> I am finding that the initial cvs checkout operation is very
> sloooooow.  Could you put up a tar.gz of the tree that the initial
> checkout makes, to get us all going?

Are you using the -z9 option when you do the checkout?

-Fred

Re: Direct CVS Access to egcs sources

[Jeffrey A Law]

  In message < m2vhvilktn.fsf@altera.gaithersburg.md.us >you write:
  > I am finding that the initial cvs checkout operation is very
  > sloooooow.  Could you put up a tar.gz of the tree that the initial
  > checkout makes, to get us all going?
I'd prefer not to, but if it becomes absolutely necessary we can
look into that.

You might want to compress the CVS data going across the wire via
cvs -z 9 <args>

That might help.  

jeff