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
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 leaving
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
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 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
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
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
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 different
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 not
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
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 contemplating
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-snmp v4.2.4. I am
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:
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
22 matches
Mail list logo
