xfs
[Top] [All Lists]

Re: Hacking XFS (was Re: reserve space for root?)

To: linux-xfs@xxxxxxxxxxx
Subject: Re: Hacking XFS (was Re: reserve space for root?)
From: Ethan Benson <erbenson@xxxxxxxxxx>
Date: Tue, 27 Aug 2002 23:51:19 -0800
In-reply-to: <Pine.LNX.4.44.0208271709340.6982-100000@stumpy.chowhouse.com>; from james@stumpy.chowhouse.com on Tue, Aug 27, 2002 at 05:16:43PM -0600
Mail-copies-to: nobody
Mail-followup-to: linux-xfs@xxxxxxxxxxx
References: <20020827230303.EAHS2113.imf22bis.bellsouth.net@TAZ2> <Pine.LNX.4.44.0208271709340.6982-100000@stumpy.chowhouse.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Tue, Aug 27, 2002 at 05:16:43PM -0600, James Rich wrote:
> 
> On Tue, 27 Aug 2002, Greg Freemyer wrote:
> 
> > One general comment, weekly or daily summaries are nice, but a
> > cumulative list is even better.
> 
> I could keep each weekly summary which could then be grouped together for
> a cumulative summary.  Not any more work really.
> 
> > You could start a new cumulative list every time a release came out.
> >
> > If you decide to go that way, I think a ID # would be good to have for
> > each line.
> >
> > That way, the experts can tell us, get the xfs 1.1 release with the #1
> > and #2 patches and see if it fixes your problem.
> 
> The only problem there is that I don't think patches are available for
> each individual checkin.  And since SGI uses its own internal source
> control system I'm not sure the individual checkins could be pulled from
> CVS.  So you wouldn't be able to get (for example) release 1.2 with
> patches 20020914-3 and 20020923-1.  I might be wrong, though.  Numbering
> the summaries wouldn't be hard, but a link to the CVSweb files would solve
> two suggestions:  a list of the files changed and an ID number (revision
> number) of the change.  So I guess I'll just link to CVSweb.

except cvs is to broken to handle complicated concepts like renaming
and moving things, which SGI's revision control does, and SGI folks
take advantage of routinly. thus cvsweb will be broken in these
instances. 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

-- Attached file included as plaintext by Ecartis --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj1sgPcACgkQJKx7GixEevwc3ACeKaJjcXVDYb63pzYqLUhoo33m
tUIAn3K8bs1pNkCNz7VdoK3ZVtje+Oae
=7qag
-----END PGP SIGNATURE-----



<Prev in Thread] Current Thread [Next in Thread>