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 scenario, how
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.
ref. CVS
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
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
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 package
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
$ cp
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).
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 tone of my
Question:
I am looking at implementing the following sequence of events in a redesign fo the
weblet:
(this is the weblet as we are now defining it, a web application that is seperate from
the underlying sh-httpd server)
-
system starts boot
all packages finish
Thanks for the feedback!
From: Erich Titl [mailto:[EMAIL PROTECTED]]
Sent: Thu 7/11/2002 11:37 AM
It will be great to have that much autoconfiguration in the 'weblet'.
Do you think it would be a big overhead to run this 'real time' e.g. when
the dashboard is requested. That way even a
I am looking at implementing the following sequence of events in a
redesign fo the weblet:
(this is the weblet as we are now defining it, a web application that
is seperate from the underlying sh-httpd server)
-
system starts boot
Handled by syslinux...
all packages
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 staff
On Wed, 10 Jul 2002, Eric Spakman wrote:
[...]
Re: the value of uClibc...
I think it is good that someone is doing this, but it is also good to be
clear that the gain in code size comes at a potential narrowing of
applicability due to incompatibility with glibc. For closed boxes,
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
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 its 1.0
My message may have been a bit confusing. This is the weblet
Richard and this is for some changes I'm making to the weblet. The
only thing that needs to be generated on startup is the collection of
what packages are there, both all the genearal packages and any weblet
addons.
The packages are
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 to this
On Thursday 11 July 2002 14:36, Charles Steinkuehler wrote:
weblet runs script to gather all package conf files
(/var/lib/lrpkg/*.conf files) to generate the configuration display
component in weblet (to replace the hard coded one in the Dev Demo
now)
We can add an init.d script to do
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.
Here is a small but
19 matches
Mail list logo
