I was investigating case sensitivity, thinking that it was somehow
necessary for the support of Windows clients, when it occurred to me
that the _only_ value-added feature this provides is that Windows users
don't need to specify the case of files and paths correctly in remote
commands.
We once
We once had the minor problem that somehow files showed up twice
(e.g. doing an update). It turned out that the case of the file itself
didn't
match the entry in the entries file. So cvs once reported the file from
the entries file and then again while looking for unknown files. It
behaved
We once had the minor problem that somehow files showed up twice
(e.g. doing an update). It turned out that the case of the file itself
didn't
match the entry in the entries file. So cvs once reported the file from
the entries file and then again while looking for unknown files. It
behaved
Is it just me, or is this getting way too complex to be usable except by
CVS experts?
I thought I was comfortable with the issues surrounding branches and
merges, even though we are not using branches yet here. But I don't
understand half of what you folks are saying.
Worse: in my
Hi,
in my company we have a Java web project that we control with CVS. When we
do a release build, we run a buildscript that starts with a cvs export -kv
on the correct tag and builds the release from there.
The project also contains a lib/ subdirectory containing (third-party)
jarfiles that had
Hi All,
We are planning to upgrade our CVS server from 1.10 version to
latest. And selected to use CVS version 1.16 or any latest. Now we
wants know the features and any pros and cons in 1.16 above.
Please
suggest and update.
--
I am building a cvs server in redhat9. I want my users to connect my server
both via pserver and ssh, and only ssh can modify the files. How to set
this? I am using xinetd. Thanks!
_
MSN Hotmail http://www.hotmail.com
Please correct me if I'm wrong. I _think_ this is the greatest common
ancestor problem. And finding one is actually something CVS does for you
- on the first mege (with a single -j). Which is usually OK in cases where
a branch immediately dies (i.e. becomes dormant) afterwards.
The problem is
Greg A. Woods [mailto:[EMAIL PROTECTED] wrote:
[ On Tuesday, November 4, 2003 at 13:57:25 (-0500), Derek
Robert Price wrote: ]
Subject: Case insensitivity ad nauseum
So anyway, why _don't_ we remove the case-insensitivity support?
I can only say it should never ever have been put in in
...and suggest an enhancement.
Anyone know how?
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim.Hyslop wrote:
|It sounds like I'm going to be the sole dissenting voice here, at least so
|far. Let me explain my reasoning; it will be rather round-about, but please
|bear with me. It will (I hope) make sense in the end.
[. . . snip . . .]
|It
On Wed, Nov 05, 2003 at 10:11:45AM -0500, Jim.Hyslop wrote:
It sounds like I'm going to be the sole dissenting voice here, at least so
far. Let me explain my reasoning; it will be rather round-about, but please
bear with me. It will (I hope) make sense in the end.
snip
A file name is a label
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood wrote:
|Please correct me if I'm wrong. I _think_ this is the greatest common
|ancestor problem. And finding one is actually something CVS does for you
|- on the first mege (with a single -j). Which is usually OK in cases where
|a branch
you appear to have found it.
donald
On Wed, Nov 05, 2003 at 10:28:16AM -0500, Tony Ennis wrote:
...and suggest an enhancement.
Anyone know how?
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim wrote:
| Yes - if you use a poor editor it will not preserve the case of the
|
|filenames. FAT32, NTFS both preserve the case, even if it doesn't actually
|USE the case... It is entirely feasible to leave CVS case sensitive and
|make a note
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fabian Cenedese wrote:
|The strange thing here is that cvs is inconsequent. It should report the
|file from the entries as missing and recreate it (though not possible on
|Windows) and further should report an unknown file in the directory.
|But what
Jim.Hyslop [EMAIL PROTECTED] wrote:
...
is it generally considered
bad practise to have two files with the same name, that differ only by case,
in the same directory?
Yes.
My understanding is that the common practise on Unix
is to use all lower-case names, to avoid potential confusion.
Donald Sharp [mailto:[EMAIL PROTECTED] wrote:
It's not terribly uncommon to have both Makefile and makefile
in some build trees I've seen( and they have a different meaning
to make! ) on unix. I wouldn't want cvs to stop surporting
the ability to track this at all! It's not unreasonable to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tony Ennis [EMAIL PROTECTED] writes:
...and suggest an enhancement.
Anyone know how?
The developers read e-mail sent to this address [EMAIL PROTECTED].
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
On Wed, 2003-11-05 at 07:34, bangke bangke wrote:
I am building a cvs server in redhat9. I want my users to connect my server
both via pserver and ssh, and only ssh can modify the files.
Yup, standard stuff.
How to set
this? I am using xinetd. Thanks!
How far have you gotten? Have you
Steve McIntyre [mailto:[EMAIL PROTECTED] wrote:
Another point I'd like to make: labels are case-sensitive
already. Live with it.
I think you missed my main point: *why* should the user have to deal with
it? Just because that's the way it works? Well then, let's *change* the
way it works, so
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 10:38:02 AM:
No. The GCA has not changed and CVS determines it correctly. You
simply no longer wish to merge from the GCA forward because some of
those changes were already merged to your destination (from another
branch and at your
On Wed, Nov 05, 2003 at 08:55:38AM +, Andy Jones wrote:
Is it just me, or is this getting way too complex to be usable except by
CVS experts?
I thought I was comfortable with the issues surrounding branches and
merges, even though we are not using branches yet here. But I don't
On Wed, Nov 05, 2003 at 11:35:12AM -0500, Jim.Hyslop wrote:
Steve McIntyre [mailto:[EMAIL PROTECTED] wrote:
Another point I'd like to make: labels are case-sensitive
already. Live with it.
I think you missed my main point: *why* should the user have to deal with
it? Just because that's the way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Robert Price wrote:
| Jim.Hyslop wrote:
|
| |It sounds like I'm going to be the sole dissenting voice here, at
least so
| |far. Let me explain my reasoning; it will be rather round-about, but
please
| |bear with me. It will (I hope) make sense
Recently, we had issues at my company which revolved around CVS branches
being forgotten. That is, work was done, but the branches were never merged
on to the mainline. While this is a mistake on the developers' part, that
is of little comfort to the project manager who is responsible for the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood [EMAIL PROTECTED] writes:
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 10:38:02 AM:
No. The GCA has not changed and CVS determines it correctly. You
simply no longer wish to merge from the GCA forward because some of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tony Ennis wrote:
|...and suggest an enhancement.
|
|Anyone know how?
Politely, deferentially, respectfully, ... oh! That's not what you
meant, is it? ;)
Derek
- --
~*8^)
Email: [EMAIL PROTECTED]
Get CVS support at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood wrote:
|Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 10:38:02 AM:
|
|No. The GCA has not changed and CVS determines it correctly. You
|simply no longer wish to merge from the GCA forward because some of
|those changes were
Derek Robert Price [mailto:[EMAIL PROTECTED] wrote:
Are you volunteering to maintain this code? I'm getting sick
of it. :)
Ah, well... gee, look at the time! ;-)
I don't think the overhead for such a small gain, the worth
of which is
completely dependant on personal case-philosophy, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Robert Price wrote:
| Greatest Common Ancestor, or GCA, is a term that refers to the RCS
| revision structure and always means the *more* recent revision two
| revisions have in common, often a branch point, but in the case of a
| branch of a
How do I know when a response from the CVS server will have more than one
line. I have read the documentation on the client/server protocol, but it
still leaves me with questions.
For example: Not every line that comes back to the client has one of the
responses that is found in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brice Oliver wrote:
|How do I know when a response from the CVS server will have more than one
|line. I have read the documentation on the client/server protocol, but it
|still leaves me with questions.
The obvious place to look would be in the CVS
Brice == Brice Oliver [EMAIL PROTECTED] writes:
Brice To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Brice Subject: Server Responses
Brice Date: Wed, 5 Nov 2003 14:46:54 -0500
Brice I would like to parse the responses from the server. Any good
Brice suggestions?
You might be interested
--- Forwarded mail from [EMAIL PROTECTED]
Steve McIntyre [mailto:[EMAIL PROTECTED] wrote:
Another point I'd like to make: labels are case-sensitive
already. Live with it.
I think you missed my main point: *why* should the user have to deal with
it? Just because that's the way it works? Well
brice How do I know when a response from the CVS server will have
brice more than one line. I have read the documentation on the
brice client/server protocol, but it still leaves me with questions.
brice For example: Not every line that comes back to the client has
brice one of the responses
Brice Oliver writes:
How do I know when a response from the CVS server will have more than one
line. I have read the documentation on the client/server protocol, but it
still leaves me with questions.
Then you need to read it again. And again. Until you really understand
it. It has been
Jim.Hyslop writes:
From the time we first learned to read, we have never considered the case of
a word to be significant in determining the identity of an object being
referred to.
That simply is not true, there are times when case is significant. The
words Polish and polish, for example.
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 12:43:14 PM:
Greatest Common Ancestor, or GCA, is a term that refers to the RCS
revision structure and always means the more recent revision two
revisions have in common, often a branch point, but in the case of a
branch of a branch and
Jim.Hyslop [EMAIL PROTECTED]
WeLl mAdE ArguMent...
No, not at all. For example, of the 111 items in my home directory
right now, 17 of them use upper-case letters in a meaningful
way. Common practice is to name some things on Unix in a mixture of
cases, e.g. Makefile, Imakefile, ChangeLog.
Hi!
Firstly, if you are using the release version 1.10 then there is a major
security release in version 1.11.5. This information is available at the
cvshome site I have refered you to. If you go through the news of the
release version you will be able to find that out.
QUOTE
2003-01-20: CVS
41 matches
Mail list logo
