On Mon, 2010-11-22 at 23:11 +0100, KP Kirchdoerfer wrote:
> Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke:
> > On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote:
> > > David;
> > >
> > > Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke:
> > > > On Sun, 2010-10-31 at
Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke:
> On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote:
> > David;
> >
> > Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke:
> > > On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> > > > Am Freitag, 29. Oktober 20
On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote:
> David;
>
> Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke:
> > On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> > > Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
> > >
> > > Ok; I propose:
> > > - just "c
David;
Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke:
> On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> > Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
> >
> > Ok; I propose:
> > - just "core" and "contrib" repository (names are not fixed), testing
> > isn't nee
On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
-snip-
> Ok; I propose:
> - just "core" and "contrib" repository (names are not fixed), testing isn't
> needed - we can also put packages in contrib which we consider for testing
> or provided as-is.
> - lrp's and sources are required fo
On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote:
> Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew:
>
> Ok; I propose:
> - just "core" and "contrib" repository (names are not fixed), testing isn't
> needed - we can also put packages in contrib which we consider for testing
> or
On Wed, 2002-07-17 at 15:50, Michael D. Schleif wrote:
> [2] Since cvs does not retain group, mode nor ownership attributes, [1]
> is further complicated and requires another kludge to correct directory
> and files attributes.
Michael,
This should only be an issue when exporting for public distri
On Wed, 2002-07-17 at 15:50, Michael D. Schleif wrote:
> I've been considering using whatever structure I settle on as my
> development environment. I have cvs setup on my own network and hope to
> integrate leaf development into my other development projects. However,
> cvs doesn't lend itself
David Douthitt wrote:
[ snip ]
> My model has been the following:
>
> archives/
> .tar.gz
> .bz2
> ...
>
> iproute2/
> distinfo
> Makefile
> patches/
> .diff
> .diff
> ...
> work/ {temporary dir; created and used to
On Wed, Jul 17, 2002 at 03:21:32PM -0500, Michael D. Schleif wrote:
>
> Jeff Newmiller wrote:
> > CVS is designed to handle directories full of information... so a
> > directory tree of html documents is a natural thing to enter.
> >
> > An idea...
> >
> > net-snmp/
> > README.txt
> >
Jeff Newmiller wrote:
>
> On Wed, 10 Jul 2002, Michael D. Schleif wrote:
[ snip ]
> > I am starting to realize that, perhaps, I should take a directory based
> > approach to helices' cvs tree.
> >
> > I have not settled on any particular structure. However, I am wondering
> > about several th
On Wed, Jul 10, 2002 at 01:01:27PM -0700, Jeff Newmiller wrote:
>On Wed, 10 Jul 2002, Michael D. Schleif wrote:
>CVS is designed to handle directories full of information... so a
>directory tree of html documents is a natural thing to enter.
>
>An idea...
>
> net-snmp/
>README.txt
>packa
On Wed, Jul 10, 2002 at 02:19:58PM -0500, Michael D. Schleif wrote:
>[1] Should I have separate trees for different underlying versions of
>net-snmp? For example, I committed net-snmp v4.2.4. I am contemplating
>building and committing both v4.2.5 and the totally different
>distribution v5.x.
Ugh, I just reverted to the prior enforce script. I'll take a look at it
again in the morning.
Currently lowercase name enforcement is active.
On Tue, 2002-07-16 at 17:12, Mike Noyes wrote:
> Everyone,
> I just removed the lowercase enforcement from our repository. If win
> clients start leavin
Everyone,
I just removed the lowercase enforcement from our repository. If win
clients start leaving broken stub files in our repository, we'll need to
reexamine this issue.
On Thu, 2002-07-11 at 16:59, Mike Noyes wrote:
> On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> > You should not fo
On Wed, Jul 10, 2002 at 01:14:07PM -0700, Mike Noyes wrote:
> On Wed, 2002-07-10 at 13:01, Jeff Newmiller wrote:
> > David Douthitt has advocated (and it sounds good to me but I haven't done
> > it myself) a mechanism whereby sources obtained from other sources are
> > kept in original form and a
On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> I had a quick look at the enforce scripts.
Manfred,
Thanks for taking a look. :-)
Note: the enforce scripts were written by Jacob Moorman, and copied from
the sitedocs cvsroot. I modified the directory and permissions files for
our repository.
Mike Noyes schrieb:
>
> On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote:
> > Mike Noyes schrieb:
> > > On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > > > Manfred,
> > > > I looked at this example again, and I think the sequence below is an
> > > > accepatble solution for it.
> > >
> > >
On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote:
> Mike Noyes schrieb:
> > On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > > Manfred,
> > > I looked at this example again, and I think the sequence below is an
> > > accepatble solution for it.
> >
> > Here is a small but significant addition
Mike Noyes schrieb:
>
> On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > Manfred,
> > I looked at this example again, and I think the sequence below is an
> > accepatble solution for it.
>
> Here is a small but significant addition to this sequence. It will allow
> retrieval of the tree in i
On Thu, 2002-07-11 at 13:17, Manfred Schuler wrote:
> Comments inline
Manfred,
Thanks for the analysis. I'm glad I don't appear to be causing problems
in our repository.
> Mike Noyes schrieb:
> > [ 547717 ] CVS repository clean-up: leaf
> >
>https://sourceforge.net/tracker/index.php?func=detail
Comments inline
Mike Noyes schrieb:
>
> On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> > It is meant as a principle when working on large projects:
> > _NEVER_ change anything that is correctly checked in
>
> Manfred,
> Incorrectly checked in files/directories are candidates for SF
Mike Noyes schrieb:
>
> On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> > Mike,
> >
> > I did _NOT_ at all want to criticize the staff at SF.
> > I know about them only what I see on the list, so I'm
> > not in a position to judge how they do their job.
>
> Manfred,
> I apologize for the
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> It is meant as a principle when working on large projects:
> _NEVER_ change anything that is correctly checked in
Manfred,
Incorrectly checked in files/directories are candidates for SF staff cvs
repository clean-up support requests (SR)
On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> Manfred,
> I looked at this example again, and I think the sequence below is an
> accepatble solution for it.
Here is a small but significant addition to this sequence. It will allow
retrieval of the tree in its 1.0 state.
$ cvs -q tag R_1_0
> $ c
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> I think I didn't express clearly what I mean.
>
> It is meant as a principle when working on large projects:
> _NEVER_ change anything that is correctly checked in
>
> I will give you an example of what I mean:
>
> In version 1.0 of pa
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> Mike,
>
> I did _NOT_ at all want to criticize the staff at SF.
> I know about them only what I see on the list, so I'm
> not in a position to judge how they do their job.
Manfred,
I apologize for the tone of my last message. It was inappropr
Mike,
I did _NOT_ at all want to criticize the staff at SF.
I know about them only what I see on the list, so I'm
not in a position to judge how they do their job.
I think I didn't express clearly what I mean.
It is meant as a principle when working on large projects:
_NEVER_ change any
On Thu, 2002-07-11 at 03:56, Manfred Schuler wrote:
> Mike Noyes schrieb:
> > If we had shell access to the repository, we would hand edit the
> > structure change. SF doesn't allow us shell access to the cvs server, so
> > we need to open SF support requests to make changes like this.
> >
> > re
Mike Noyes schrieb:
[snip]
> > What happens when I decide that /usr/sbin/ntp_setup actually belongs
> > /usr/bin/ntp_setup? Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp?
> >
> > Clearly, cvs cannot know my intent, in this regard. When committing a
> > directory change, under this scena
On Wednesday 10 July 2002 19:41, Michael D. Schleif wrote:
> Yes, these are our (leaf) _cvs_ versions. However, how can a user
> select net-snmp v4.2.4 when my net-snmp version is 1.1?
Well, the editor session that pops up during a commit can be avoided
with the -m "text" switch added to the co
On Wed, 2002-07-10 at 17:41, Michael D. Schleif wrote:
>
> Mike Noyes wrote:
> >
> > On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> > CVS retains all previous versions of a file in the repository. You can
> > specify a specific version for retrieval.
> >
> > Example:
> >
>http://cvs.
Mike Noyes wrote:
>
> On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> >
> > Jeff Newmiller wrote:
> > >
> > > On Wed, 10 Jul 2002, Michael D. Schleif wrote:
> >
> > > > [1] Should I have separate trees for different underlying versions of
> > > > net-snmp? For example, I committed net-
On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
>
> Jeff Newmiller wrote:
> >
> > On Wed, 10 Jul 2002, Michael D. Schleif wrote:
>
> [ snip ]
>
> > > [1] Should I have separate trees for different underlying versions of
> > > net-snmp? For example, I committed net-snmp v4.2.4. I am co
On Wed, 2002-07-10 at 15:39, Charles Steinkuehler wrote:
> > Under this scenario, committing to cvs directory structures, cvs is
> > responsible for knowing whether or not a specific file or directory
> > has changed? Any change, including mod/grp/own?
>
> CVS doesn't track file permissions or o
> Yes, I agree. However, I am dealing with somebody else's software and
> making it suitable for leaf. Obviously, I can have several iterations
> of net-snmp v4.2.4 that address various leaf concerns.
>
> Also, I must be prepared for somebody else's version upgrades causing
> problems that do no
Jeff Newmiller wrote:
>
> On Wed, 10 Jul 2002, Michael D. Schleif wrote:
[ snip ]
> > [1] Should I have separate trees for different underlying versions of
> > net-snmp? For example, I committed net-snmp v4.2.4. I am contemplating
> > building and committing both v4.2.5 and the totally diffe
On Wed, 2002-07-10 at 13:01, Jeff Newmiller wrote:
> David Douthitt has advocated (and it sounds good to me but I haven't done
> it myself) a mechanism whereby sources obtained from other sources are
> kept in original form and a parallel directory containing patchfiles and
> compilation instructi
On Wed, 10 Jul 2002, Michael D. Schleif wrote:
>
> Mike and I were discussing cvs off-list. Since much of this is
> un-structured now, perhaps, we can impose some user-friendly and
> consistent form on our cvs tree.
A topic with a long history...
> I am starting to realize that, perhaps, I sh
On Wed, 2002-07-10 at 12:19, Michael D. Schleif wrote:
>
> Mike and I were discussing cvs off-list. Since much of this is
> un-structured now, perhaps, we can impose some user-friendly and
> consistent form on our cvs tree.
Michael,
Remember that your devel/helices tree structure is entirely up
At 2002-01-07 11:07 +0100, Ewald Wasscher wrote:
>Mike Noyes wrote:
>>The last thing I did before disappearing for the last couple of months,
>>was to restructure our CVS repository. All developers now have a personal
>>tree in devel/yourname. There is a bin directory for released files. The
>>
Mike Noyes wrote:
> Everyone,
> The last thing I did before disappearing for the last couple of
> months, was to restructure our CVS repository. All developers now have
> a personal tree in devel/yourname. There is a bin directory for
> released files. The oxygen and dachstein trees are contro
On Fri, 20 Apr 2001, Mike Noyes wrote:
> [EMAIL PROTECTED], 2001-04-20 17:26 -0700
> >On Fri, 20 Apr 2001, Mike Noyes wrote:
> > > I thought this might be a good way to write protect hard drives
> > > and flash disks.
> >
> >Perhaps... or it may actually be _too_ restrictive, since you simply
>
[EMAIL PROTECTED], 2001-04-20 17:26 -0700
>On Fri, 20 Apr 2001, Mike Noyes wrote:
> > That doesn't sound good, but how is it different from the backup
> > scripts we use now?
>
>The disk need not be accessed for months at a time in an LRP box.
Jeff,
Understood. Thanks for taking the time to expla
On Fri, 20 Apr 2001, Mike Noyes wrote:
> [EMAIL PROTECTED], 2001-04-20 16:30 -0700
> >On Fri, 20 Apr 2001, Mike Noyes wrote:
> >
> > > David Douthitt, 2001-04-20 16:25 -0500
> > > >I like the long name idea, using VFAT. The only thing is, VFAT adds
> > > >FAT to the kernel (pun intended :-) Jus
[EMAIL PROTECTED], 2001-04-20 16:30 -0700
>On Fri, 20 Apr 2001, Mike Noyes wrote:
>
> > David Douthitt, 2001-04-20 16:25 -0500
> > >I like the long name idea, using VFAT. The only thing is, VFAT adds
> > >FAT to the kernel (pun intended :-) Just how big is this thing?
> >
> > Would someone expla
On Fri, 20 Apr 2001, Mike Noyes wrote:
> David Douthitt, 2001-04-20 16:25 -0500
> >I like the long name idea, using VFAT. The only thing is, VFAT adds
> >FAT to the kernel (pun intended :-) Just how big is this thing?
>
> Would someone explain to me why we shouldn't use cramfs? I believe it wo
David Douthitt, 2001-04-20 16:25 -0500
>I like the long name idea, using VFAT. The only thing is, VFAT adds
>FAT to the kernel (pun intended :-) Just how big is this thing?
Would someone explain to me why we shouldn't use cramfs? I believe it works
with floppies too.
http://www.linuxdevices.c
Man, I am so swamped. Ladybug needs to be whacked against the new Oxygen
release -- this shouldn't be too big of a deal, since the new Oxygen has
a fair number of the architectural changes I was working on built into
it (only better). So the work at this point is a matter of kernel
customization,
VERY informative, Jeff! Very much appreciate this new information
[EMAIL PROTECTED] wrote:
> vfat is backward-compatible. Microsoft used reserved features in the FAT
> format to implement its features, and included consistency checks with
> fallback to 8.3 behavior in case an older MSDOS sy
On Fri, 20 Apr 2001, George Metz wrote:
> On Fri, 20 Apr 2001, David Douthitt wrote:
>
> > Not a bad idea; however, there are a few things that come to mind:
> >
> > * How do you create a VFAT diskette under Windows? Some may laugh; I
> > for one am not sure how
>
> Beats me. I think it's
On Fri, 20 Apr 2001, David Douthitt wrote:
> Not a bad idea; however, there are a few things that come to mind:
>
> * How do you create a VFAT diskette under Windows? Some may laugh; I
> for one am not sure how
Beats me. I think it's a simple matter of formatting under Windows. I'll
give it
David Douthitt, 2001-04-20 11:24 -0500
>I've had it up to here with all the different package formats - and
>none of them satisfy the above requirement. I've HP-UX boxes here
>(Software Depots), Unixware ("Packages"), Red Hat Linux (RPM), and
>until recently Debian (DEB). Makes me want to do wha
> > If so, I
> > think a separate tree for packages is in order. I also, like David's
diff
> > idea for them.
>
> This doesn't necessarily help in this case, though: the distributions
> now present are starting to show direct incompatabilities:
>
> * glibc 2.0.7 vs. glibc 2.1.3 vs. glibc 2.2 (futu
Charles Steinkuehler wrote:
> > These are the things I've thought about, and my opinions on them:
> >
> > * Include versions in the package name - not enough name space.
>
> Why not require VFAT support? I don't think it adds too much size to a
> compressed kernel.
Not a bad idea; however, the
> Getting back to your CVS comments from yesterday. I agree, we need to
start
> committing files to CVS. There are approximately six people working
> independently on the EigerStein update. Putting these individual pieces
> into CVS will allow all of us to build off of each others efforts.
>
> Fir
David Douthitt, 2001-04-20 10:22 -0500
> > How close are you to committing the Oxygen devel tree to CVS?
>
>The CDROM contains a direct image of the Oxygen development source
>tree, along with the packages. Everything in src/base is either a
>binary in the system or a package on the boot disk. E
Mike Noyes wrote:
> Third, does anyone have suggestions for the tree structure?
Didn't we already hash that out?
I like separate directories or CVS trees for each of the significant
distributions (base). Packages should probably be separate the
only interesting complication is that some sy
Charles Steinkuehler, 2001-04-20 08:45 -0500
>It'd be interesting to see how much each option affected size, but
>overall a 411K 2.4 kernel is VERY COOL, and should be quite usable for
>floppy firewalls. While I'd like to see a 'one size fits all' kernel,
>perhaps there could be a floppy only, mi
59 matches
Mail list logo
