Re: history and val-tags locks.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Derek Price wrote:
Derek Price wrote:
I see your point. What about `cvs server'? I
can see both setups being useful... an admin
who allowed users access to the CVS repository
would probably prefer not to allow the config
file to be specified whereas an admin who
restriced the command that SSH users could run
to a particular shell script that provided the
-c option wouldn't mind... perhaps it should
be a compile time option, with the default to
disallow it.
On further consideration, if we are going to
consider a configurable config path with other
CVS modes a security risk, then using it with
pserver has to be considered a security risk
too. There is nothing stopping a creative user
with shell access to a machine from using
pserver mode to access their repository.
I might argue that any administrator worried
that much about security should be disabling
shell access to the machine anyhow, which would
deal with any insecurity resulting from a
configurable config path, but I don't feel so
strongly about it that I wouldn't happily
install it as a compile-time option that
defaults to off.
I've implemented this as an option to server
pserver. Installing as a global option would
have create problems in multiroot mode anyhow.
True.
Preliminary patch against 1.11.x attached. The
final version will go into feature - I'm not
advocating putting this in stable, but this is
what I have now and I thought I would request a
review.
okay.
This patch also finally disables the
sourcing of the ~/.cvsrc file for the server
commands as an added protection against a user
setting the path to the config file.
2005-05-17 Derek Price [EMAIL PROTECTED]
* configure.in: Add --enable-config-override.
* main.c (main): Don't source .cvsrc in server mode.
Remove obsolete comment.
* parseinfo.c (ConfigPath): New global.
(parse_config): Open ConfigPath when provided.
* server.c (server): Parse -c option.
* sanity.sh (server_usage): New static global.
(sever): Add tests of ConfigPath and .cvsrc.
I've been thinking about this more, and I'm
starting to feel that as an option to
server/pserver/etc, this really isn't so
insecure. In general, an admin will be able to
and probably does restrict the arguments to the
server pserver commands, and a user with shell
access to the server could run a hacked CVS
against a repo or even alter a repo directly
anyhow, so the argument about security is mostly
moot.
For pserver, the administrator has full control over
the command line.
For server, if the administrator is using a
restricted shell for users, they may or may not be
able to restrict command-line arguments (it
depends on how the restricted shell is
implemented).
The only exception would be where the admin only
used a setuid CVS executable to restrict repo
access to a specific CVS executable. I'm not
sure how common this is however, as it also
disables the ability to use UNIX uids gids for
finer control over read write access.
I have used (am using) a set-gid cvs and it does
not disable the use of UNIX uids at all. Yes, it
does inhibit gids as the entire repository uses
the same gid ('cvs'), but the cvs_acls deals with
permissions for commit and anyone with a login to
the special-purpose CVS server has already been
granted read permissions for checkout in any case.
I will grant you that this is not necessarily a
normal situation, but I make note of it as setuid
is not the only configuration possiblity here.
For the patch, if you want the
- --enable-config-override to be a configure and
compile-time option, I don't have any strong
objections to it as long as it defaults to
the more paranoid configuration. So, the current
enable_config_override=yes is not one that I
believe should be the default.
As an alternative, I would not have a problem with
allowing cvs to be built with a list of
directories that could be searched for a valid
config file. So, a --enable-config-prefix=/etc/cvs
might mean that /etc/cvs/$CVSROOT/config would looked
at before $CVSROOT/config ... doing that means that
the administrator would still have complete control
over the configurations and would not need to rely
on the user to make the right choice.
The downside is that src/sanity.sh tests for this
case would be more painful.
Your change to src/main.c looks fine.
While I would favor another mechanism for config
override, the code you have written for
src/parseinfo.c does appear to work as you suggest
As far as your src/sanity.sh tests, I believe you
should use the -c CONFIG-FILE to determine if cvs
has been configured with this option or not before
you fail the tests (granted STABLE does not have
that available to sanity.sh)
As far as src/server.c, the code looks reasonable
for what you are attempting.
-- Mark
-BEGIN PGP SIGNATURE-
Re: history and val-tags locks.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
For pserver, the administrator has full control over
the command line.
For server, if the administrator is using a
restricted shell for users, they may or may not be
able to restrict command-line arguments (it
depends on how the restricted shell is
implemented).
For server, OpenSSH, at the very least, allows
the command line to be restricted. Are we really
worried about the security of the command line
if the user is still using a vulnerable tool
like RSH to access their server?
Well, I would like to try not to impose
implementation decisions on administrators if
possible. Just because the
$HOME/.ssh/authorized_keys file is able to specify
a command= parameter for OpenSSH does not mean that
is the only version of secure transport that exists
(cf gssapi).
I have used (am using) a set-gid cvs and it
does not disable the use of UNIX uids at all.
Yes, it does inhibit gids as the entire
repository uses the same gid ('cvs'), but the
cvs_acls deals with permissions for commit and
anyone with a login to the special-purpose CVS
server has already been granted read
permissions for checkout in any case.
I will grant you that this is not necessarily a
normal situation, but I make note of it as setuid
is not the only configuration possiblity here.
Well, no, but for a secure setup, aren't we
still recommending that the admin rely on a
transport such as SSH and filesystem permissions
or ACLs for access restriction in the
repository?
Yes.
The stated position of the CVS developers has
been that users should rely on systems that get
more thorough security audits than CVS does to
provide the secure portions of their setups.
Yes.
This means using SSH as a transport, restricting
the command line, and relying on system
permissions/ACLs to restrict access to the
various portions of a repository.
Sure, but is would be better to not make for
fragile configurations that are accidentally
broken by administrators who do not understand
the subtle holes that might be available.
setuid and setgid CVS executables both disable
the fine-grained access restrictions that would
otherwise be possible, limiting you, basically,
to one group per repository/server.
Actually, one rational for going to a set-gid CVS
executable was that there were so many groups in
use on the system that it exceeded the Solaris
maximum number at the time. Letting everyone play
with a set-gid executable gave them an extra group
without burning thru the maximum number allowed by
the OS.
Fine grained access can go to far in some cases
and it is best to allow the administrators as much
flexibility as possible.
As an alternative, I would not have a problem with
allowing cvs to be built with a list of
directories that could be searched for a valid
config file. So, a --enable-config-prefix=/etc/cvs
might mean that /etc/cvs/$CVSROOT/config would looked
at before $CVSROOT/config ... doing that means that
the administrator would still have complete control
over the configurations and would not need to rely
on the user to make the right choice.
This compromise does sound reasonable. Would you
then consider a default value of
`--enable-config-prefix=/etc' as reasonable
here? i.e. the ability to override the config
would default to `on', with access to config
files restricted to /etc and subdirs.
Sure. However, /etc is fairly crowded which is why
I suggested /etc/cvs as an alternative.
The downside is that src/sanity.sh tests for this
case would be more painful.
Well, we could test that the restricted paths
were disabled, at least.
Sure.
As far as your src/sanity.sh tests, I believe you
should use the -c CONFIG-FILE to determine if cvs
has been configured with this option or not before
you fail the tests (granted STABLE does not have
that available to sanity.sh)
If it defaults to on, with config-prefix used as
you suggest, would you still consider this last
important?
No. If we go with a config-prefix, then defaulting to ON
would be okay in my opinion.
Note: It may be desirable to consider
config-prefix to be a prefered list of directories
with the last directory searched being
$CVSROOT/CVSROOT ... So,
--config-prefix='/etc/cvs:/usr/local/etc/cvs'
would mean that the config file would be the first
of
/etc/cvs/$CVSROOT/config
/usr/local/etc/cvs/$CVSROOT/config
$CVSROOT/CVSROOT/config
that existed.
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCi6PI3x41pRYZE/gRAqcEAJ9iujX545bLiG28OHM+2JXob/nl0QCgyTLa
fNJYVUPgm/bZ2ofYQB2fD3E=
=gGYI
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: lockinfo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kendy Kutzner [EMAIL PROTECTED] writes:
On 2005-05-09T11:25:06-0700, Mark D. Baushke wrote:
- empty/nonexistent lockinfo: everything should work as ever
- layout $CVSROOT/a, $CVSROOT/a/b, $CVSROOT/c
- lockinfo contains
^a false
^a/b true
- checkout a should fail
- checkout b should work (i'm not too sure)
I believe CVS processes directories
alphabetically depth-first. So, in this case,
b would also fail unless you explicitly did a
cvs checkout a/b
you are right, that's what i'm talking about
when i wrote 'checkout b'
Okay. I just wanted to be clear what was the
expected output of the designer of the patch.
In point of fact, the addition of this new
feature may be a good time to alter how cvs
works.
as long as i don't have to write it :)
Yup, I understand that feeling very well indeed... :-)
If you are explicitly controlling checkout
behavior, then you could choose to non-fatally
skip directories for which you do not have
permissions... it would be as if they were
really private to some other set of users and
not even visible to the user implicitly trying
to check them out.
Than CVS internals really have to be changed. My
little patch makes the lock creation fail. When
lock creation fails, CVS aborts the current
operation. One possible change: first lock all
directories which are going to be used. If all
locks were successfully created, do the
checkout: somehow
if (start_recursion(lock..)){
start_recursion(checkout..)
start_recursion(unlock..)
}
Yeah, it really would be easier to implement this
variation in a read-lock trigger if CVS were using
the lock manager of CVSNT instead of the current
way it does locks.
However, I don't really want to worry about that
feature of CVSNT right now.
Although it may be desirable to force an error
if the user explictly asked for a
'read-locked' directory on the command line
instead of just running into one during the
checkout process.
But as I said, that's exactly the behaviour when
someone enforces 'dont read (dont create locks)'
with file system permissions.
Okay.
Addition of this kind of 'read-lock' might be
considered to be 'better' than just use
operating-system directory permissions.
It's not that elegant, but more flexible. And it
works with all kinds of file systems.
Well, your patch acts in addition to the locks
imposed by ther other kinds of file systems
already supported...
I still remain unconvinced that the current
implementation of your patch is desirable.
Since my patch is GPL, everyone is free to
change it / ignore it. In which direction do you
would change it?
I am not sure.
+Before the lock is created, the @file{loginfo} in CVSROOT is
The above line references `loginfo' instad of
`lockinfo' which seems wrong.
Because it is wrong :)
But I think I don't need to send a patch for that :)
True.
I suspect that some mention that this is for
read-locks instead of dealing with promotable
or write locks...
I thought write locks are an entire different
ball game? But feel free to correct me.
Sure, but the paragraph you added leaves ambiguity
that the trigger might also apply for other kinds
of locks. The idea would be to be clear in the
documentation that this particular trigger is NOT
used for anything other than read-locks.
it also begs the question as to the correct
name for this file being 'readinfo' instead of
'lockinfo' ...
As I wrote, anybody can change that.
Sure.
Okay. The patch is posted and there is at least
some idea of how to write the sanity.sh tests
for trivial exercise of it.
I honestly don't know if it is a good idea to
introduce this patch to feature in this way at
this time.
What do the other maintainers think of this kind
of extension?
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCgHbI3x41pRYZE/gRAqHNAJ9pN3V1IoCW56tFqhZyNYsoOye16ACgixS3
GIQQcdhLtqlnGzrMl5zK9IM=
=AwyR
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Build CVS (TRUNK) failed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino [EMAIL PROTECTED] writes: Hi Mark, From: Mark D. Baushke Sent: Sunday, May 08, 2005 13:48 lib\unistd-safer.h should be what gets used. It was added via a GNULIB update, so it should be there. Last night's test results build worked as did mine this morning. Microsoft Visual C (MVC) has a different opinion for *.dep and *.mak file content. Unless there's something I'm unaware of I plan to commit the following patch tomorrow. Given that I 'manually' generated the changes for the MVC files, I have no objections to real versions of those files being committed. You might as well commit the patch today. Thanks! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCf6hB3x41pRYZE/gRAri+AKDH7RuHq02tZJrNdvz6q88GT/b/fgCeL9Yz crXzBaMST1NHZVlDGJPeuG0= =yBAU -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: lockinfo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kendy Kutzner [EMAIL PROTECTED] writes:
On 2005-05-06T09:09:37-0700, Mark D. Baushke wrote:
To be considered for inclusion in a CVS FEATURE release, you should
provide changes to the doc/cvs.texinfo
attached
Comments included inline below...
as well as at least a few test
cases (if you don't understand how to work with sanity.sh that is okay,
but we need a series of step-by-step commands that illustrate how to
verify that everything works with your new feature and how the new
feature interacts with existing features).
I didn't get everything from sanity.sh, but here are some ideas for test
cases:
- empty/nonexistent lockinfo: everything should work as ever
- layout $CVSROOT/a, $CVSROOT/a/b, $CVSROOT/c
- lockinfo contains
^a false
^a/b true
- checkout a should fail
- checkout b should work (i'm not too sure)
I believe CVS processes directories alphabetically depth-first. So, in
this case, b would also fail unless you explicitly did a
cvs checkout a/b
- checkout c should work
For this particular addition, I have a problem with how it works.
Assumption: I have a repository where there exists one directory called
Private that is 'read-locked' such that userA is able to checkout
directory Private and userB is not.
If userB starts a 'cvs checkout -d top .' command. What should you
expect to happen:
a) no files are checked out because Private will fail and that
'should' stop the checkout command from providing partial
information.
b) all directories that are processed up to, but not including the
Private directory are checked out. However, any files that
would logically have been checked out of directories after
Private are not checked out because the directory traversal
will stop when Private is first reached.
c) all directories other than Private will be checked out of the
repository and the user will receive a Lock Info failed message
that they may or may not notice indicating that the Private
directory was not checked out.
With your current patch, I believe userB will observe behavior 'b',
but I am not sure if that is true or not.
As I see it, you are right, it should be 'b'.
Yeah, this is what I expected.
It is not clear to me if behavior 'a' or behavior 'c' is the correct
behavior, but I believe behavior 'b' is not desirable.
I see your worries. But i think that's the way CVS works:
directory-by-directory. There is no commit-atomicity, there is no
lock-atomicity. I think the behaviour is comparable to a scenario where
userB does not have (file-system) write permissions to the directory.
I added the solicited changes to cvs.texinfo as well as new changes to
src/mkmodules.c to create a default version of lockinfo.
In point of fact, the addition of this new feature may be a good time to
alter how cvs works. If you are explicitly controlling checkout
behavior, then you could choose to non-fatally skip directories for
which you do not have permissions... it would be as if they were really
private to some other set of users and not even visible to the user
implicitly trying to check them out. Although it may be desirable to
force an error if the user explictly asked for a 'read-locked' directory
on the command line instead of just running into one during the checkout
process.
Addition of this kind of 'read-lock' might be considered to be 'better'
than just use operating-system directory permissions.
I still remain unconvinced that the current implementation of your patch
is desirable.
Kendy
--
Only in cvs_my/: autom4te.cache
diff -r -u cvs-1.12.12/doc/cvs.texinfo cvs_my/doc/cvs.texinfo
--- cvs-1.12.12/doc/cvs.texinfo 2005-04-14 17:56:36.0 +0200
+++ cvs_my/doc/cvs.texinfo2005-05-09 17:45:41.070237832 +0200
@@ -6569,6 +6569,16 @@
the change to @file{b/three.c} and not the change to
@file{a/two.c}.
[EMAIL PROTECTED]
+Before the lock is created, the @file{loginfo} in CVSROOT is
The above line references `loginfo' instad of `lockinfo' which seems
wrong.
+consulted. Every non-comment line in that file should
+contain a directory pattern and a filter. On the first
+match between the current active directory and the pattern
+the filter is executed with the directory as parameter. The
+special pattern ALL matches always. When the exit code of
+the filter is not zero, the lock creation failes. If the
+exit code is zero, normal lock creation procedure continues.
+
I suspect that some mention that this is for read-locks instead of
dealing with promotable or write locks... it also begs the question
as to the correct name for this file being 'readinfo' instead of
'lockinfo' ...
@node Watches
@section Mechanisms to track who is editing files
@cindex Watches
Only in cvs_my/src: autom4te.cache
diff -r -u cvs-1.12.12/src/cvs.h cvs_my/src
Re: Build CVS (TRUNK) failed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino [EMAIL PROTECTED] writes: Sorry to be tuning in late. I'm not always watching the stream. No worries. I think the current tree is fixed, but if you could turn the crank to verify it that would be great. I'm volunteering to fix this one but I need ideas on where to get a unistd-safer.h and my initial though is to hack one together line we did for windows-NT/unistd.h. What are your thoughts? lib\unistd-safer.h should be what gets used. It was added via a GNULIB update, so it should be there. Thanks! -- Mark Conrad From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, May 08, 2005 00:00 Microsoft (R) Program Maintenance Utility Version 1.62.7022 Copyright (C) Microsoft Corp 1988-1997. All rights reserved. cd .\lib NMAKE /A /F .\libcvs.mak CFG=libcvs - Win32 Release Microsoft (R) Program Maintenance Utility Version 1.62.7022 Copyright (C) Microsoft Corp 1988-1997. All rights reserved. if not exist .\WinRel/ mkdir .\WinRel tempfile.bat 1 file(s) copied. tempfile.bat 1 file(s) copied. tempfile.bat 1 file(s) copied. NMAKE : fatal error U1073: don't know how to make '..\windows-NT\unistd-safer.h' Stop. NMAKE : fatal error U1077: 'C:\Program Files\DevStudio\VC\BIN\NMAKE.EXE' : return code '0x2' Stop. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCfnsb3x41pRYZE/gRAtAKAJ0QQ9Imy9crUQ4U63JZUZhqPo9j/ACeJhAw 5Qdl14F1lFFn40qjdBK3oKo= =D4Ci -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Build CVS (TRUNK) failed.
Hi Folks, link.exe @C:\DOCUME~1\djones\LOCALS~1\Temp\nma01632. libdiff.lib(save-cwd.obj) : error LNK2001: unresolved external symbol _fd_safer .\WinRel\cvs.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x19' Stop. I suspect that something like the following patch is needed, but I don't actually have any Windows box or development environment to test it. -- Mark Index: libcvs.dep === RCS file: /cvs/ccvs/lib/libcvs.dep,v retrieving revision 1.19 diff -u -p -r1.19 libcvs.dep --- libcvs.dep 8 Mar 2005 05:16:29 - 1.19 +++ libcvs.dep 6 May 2005 07:15:21 - @@ -40,6 +40,14 @@ .\exitfail.h\ +.\fd-safer.c : \ + ..\windows-NT\config.h\ + ..\windows-NT\stdbool.h\ + ..\windows-NT\unistd.h\ + .\unistd-safer.h\ + .\error.h\ + + .\fncase.c : \ ..\windows-NT\config.h\ ..\windows-NT\ndir.h\ Index: libcvs.dsp === RCS file: /cvs/ccvs/lib/libcvs.dsp,v retrieving revision 1.20 diff -u -p -r1.20 libcvs.dsp --- libcvs.dsp 8 Mar 2005 05:16:29 - 1.20 +++ libcvs.dsp 6 May 2005 07:15:21 - @@ -109,6 +109,10 @@ SOURCE=.\exitfail.c # End Source File # Begin Source File +SOURCE=.\fd-safer.c +# End Source File +# Begin Source File + SOURCE=.\fncase.c # End Source File # Begin Source File Index: libcvs.mak === RCS file: /cvs/ccvs/lib/libcvs.mak,v retrieving revision 1.21 diff -u -p -r1.21 libcvs.mak --- libcvs.mak 8 Mar 2005 05:16:29 - 1.21 +++ libcvs.mak 6 May 2005 07:15:21 - @@ -46,6 +46,7 @@ CLEAN : [EMAIL PROTECTED] $(INTDIR)\closeout.obj [EMAIL PROTECTED] $(INTDIR)\dirname.obj [EMAIL PROTECTED] $(INTDIR)\exitfail.obj + [EMAIL PROTECTED] $(INTDIR)\fd-safer.obj [EMAIL PROTECTED] $(INTDIR)\fncase.obj [EMAIL PROTECTED] $(INTDIR)\fnmatch.obj [EMAIL PROTECTED] $(INTDIR)\fseeko.obj @@ -103,6 +104,7 @@ LIB32_OBJS= \ $(INTDIR)\dirname.obj \ $(INTDIR)\exitfail.obj \ $(INTDIR)\fncase.obj \ + $(INTDIR)\fd-safer.obj \ $(INTDIR)\fnmatch.obj \ $(INTDIR)\fseeko.obj \ $(INTDIR)\ftello.obj \ @@ -163,6 +165,7 @@ CLEAN : [EMAIL PROTECTED] $(INTDIR)\closeout.obj [EMAIL PROTECTED] $(INTDIR)\dirname.obj [EMAIL PROTECTED] $(INTDIR)\exitfail.obj + [EMAIL PROTECTED] $(INTDIR)\fd-safer.obj [EMAIL PROTECTED] $(INTDIR)\fncase.obj [EMAIL PROTECTED] $(INTDIR)\fnmatch.obj [EMAIL PROTECTED] $(INTDIR)\fseeko.obj @@ -217,6 +220,7 @@ LIB32_OBJS= \ $(INTDIR)\basename.obj \ $(INTDIR)\dirname.obj \ $(INTDIR)\exitfail.obj \ + $(INTDIR)\fd-safer.obj \ $(INTDIR)\fncase.obj \ $(INTDIR)\fnmatch.obj \ $(INTDIR)\fseeko.obj \ @@ -333,6 +337,11 @@ SOURCE=.\exitfail.c $(INTDIR)\exitfail.obj : $(SOURCE) $(INTDIR) +SOURCE=.\fd-safer.c + +$(INTDIR)\fd-safer.obj : $(SOURCE) $(INTDIR) + + SOURCE=.\fncase.c $(INTDIR)\fncase.obj : $(SOURCE) $(INTDIR) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: lockinfo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Kendy, To be considered for inclusion in a CVS FEATURE release, you should provide changes to the doc/cvs.texinfo as well as at least a few test cases (if you don't understand how to work with sanity.sh that is okay, but we need a series of step-by-step commands that illustrate how to verify that everything works with your new feature and how the new feature interacts with existing features). For this particular addition, I have a problem with how it works. Assumption: I have a repository where there exists one directory called Private that is 'read-locked' such that userA is able to checkout directory Private and userB is not. If userB starts a 'cvs checkout -d top .' command. What should you expect to happen: a) no files are checked out because Private will fail and that 'should' stop the checkout command from providing partial information. b) all directories that are processed up to, but not including the Private directory are checked out. However, any files that would logically have been checked out of directories after Private are not checked out because the directory traversal will stop when Private is first reached. c) all directories other than Private will be checked out of the repository and the user will receive a Lock Info failed message that they may or may not notice indicating that the Private directory was not checked out. With your current patch, I believe userB will observe behavior 'b', but I am not sure if that is true or not. It is not clear to me if behavior 'a' or behavior 'c' is the correct behavior, but I believe behavior 'b' is not desirable. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCe5bB3x41pRYZE/gRAijIAKCjSmhK3qaFKhr4hSzfMSGE7+OhqgCg1b3I KE0BhXnAAZJN2GdnfpgijmU= =dQ2J -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: history and val-tags locks.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Note that HistoryFile has an argument that would basically be run through strftime, to enable log rotation. Also see the HistorySearch, which would be used as a file glob to locate history files to be read for executions of the `cvs history' command. Hmmm I do not like the BSD glob(3) function and its introduction in CVS would not make sense given we already have POSIX fnmatch() available... It would be better to specify looking for history files in terms of fnmatch() semantics if that is what you intend to use to do the resolution. Hey Mark, Revisiting this since you brought it up, what don't you like about BSD glob(3)? Not all systems provide a glob(3) function. Those that do provide a glob(3) function provide many different variations of implementation because glob existed a long time before the more general fnmatch was written. If you are only planning to use the subset of flags specified by POSIX.2 for glob, then you might be okay with a number of implementations. However, my recollection is that there were a number of implementations that did follow POSIX.2 closely. I think something like these flags are 'standard': GLOB_APPEND, GLOB_DOOFS, GLOB_ERR, GLOB_MARK, GLOB_NOCHECK, GLOB_NOESCAPE, GLOB_NOSORT while some implementations will also provide additional flags like these that are found on OpenBSD and FreeBSD: GLOB_ALTDIRFUNC, GLOB_BRACE, GLOB_MAGCHAR, GLOB_NOMAGIC, GLOB_QUOTE, GLOB_TILDE, GLOB_LIMIT while some GNU implementations add GLOB_ONLYDIR, GLOB_PERIOD some glob() implementations provide those extensions, but have slightly different semantics for them. As for return values, I believe that GLOB_NOSPACE, GLOB_ABORTED and GLOB_NOMATCH are standard, but some implementations may return GLOB_NOSYS to indicate that the function is not supported. In some implementations gl_pathc and gl_offs are not of type size_t as mandated by POSIX.2, but are instead 'int' which was used in many *BSD implementatiosn for years. This can cause interesting problems unless care is taken with how you use glob(). As near as I can tell, the POSIX.2 glob spec implies that it should basically be a wrapper for fnmatch() that opens intervening directories and performs intermediate matches. I ask because I am looking at reimplementing glob at the moment to allow the history search path to include multiple directories. For example, to match a path like: HistoryLogPath=/cvsroot/CVSROOT/history/%Y/%m/%d HistorySearchPath=/cvsroot/CVSROOT/history/*/*/* I need to open /cvsroot/CVSROOT/history, open each directory that matches *, open each directory in those directories that matches *, then open each file in those directories that matches *. IT seems to me that it would be much easier to import the glibc glob() function in GNULIB style, probably by actually first importing it into a GNULIB module, then use that if the local glob() functoin doesn't look useful. I believe that most modern glob() implementations may indeed internally be implemented using fnmatch(), but not all of them are. If you are considering using an internal glob() instead of relying on a library version from the system, then I don't have as much of a problem with it. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCemka3x41pRYZE/gRAnCpAKCcCec+kR6cfo0aGPmk3G6iXnRi7gCgmFLA Fry9D/09sR2uD7pb+mOLlsc= =wiw0 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: MacOS X 10.3.7 Build Problem After CVS CheckOut
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino [EMAIL PROTECTED] writes: I'm seeing the same build problem on both stable feature: Titanium:~/projects/cvs-1.12.12 conradtpino$ make make all-recursive Making all in lib make all-am make[3]: Nothing to be done for `all-am'. Making all in zlib make[2]: Nothing to be done for `all'. Making all in diff make[2]: Nothing to be done for `all'. Making all in src rm: cvs: is a directory make[2]: *** [cvs] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Titanium:~/projects/cvs-1.12.12 conradtpino$ The problem occurs because the MacOS file system appears to be case insensitive with respect to file names i.e. both of the following do the same thing: ls CVS ls cvs I'm seeing the error for the first time because I checked out with a revision tag instead of downloading a tar ball. I can work around the problem by using export instead of checkout command. The question becomes: Is it worthwhile fixing the build to deal with case insensitive UNIX file systems? The typicaly way that I build on case-insensitive filesystems is like this: cvs checkout ccvs cd ccvs mkdir objdir cd objdir ../configure make make check this means that all of the derrived files are in the ccvs/objdir subdirectory. If I am going to build for multiple architectures out of the same set of sources, I have been known to use the following directory names: obj.macosx2 # MacOS 10.2 obj.macosx3 # MacOS 10.3 obj.solsparc9 # Solaris 9 on Sparc hardware obj.solsparc8 # Solaris 8 on Sparc hardware obj.solsparc7 # Solaris 7 on Sparc hardware obj.aix43 # AIX 4.3 obj.fbsd42 # FreeBSD 4.2-RELEASE obj.fbsd410 # FreeBSD 4.10-RELEASE obj.nbsd16 # NetBSD 1.6 obj.nbsd299 # NetBSD 2.99.15 obj.rh73# Redhat 7.3 i386 GNU/Linux obj.fc3 # Fedora Core 3 i386 GNU/Linux obj.unicos # Unicos 9.0 Cray Y-MP EL instead of 'objdir' as the place where I build and test out of one checkout of the sources... Your experience may be different. I almost never actually build directly in the 'ccvs' directory as it was checked out (I try it once per release as we are getting close to make sure it still works). Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCeGT03x41pRYZE/gRAvOQAKDKvElDg9X4RFPYGc5vtK2q1F0xGwCgxBov +hBA43zL1skrlMklP/GJtf0= =U12V -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] Re: [PATCH] mmap-anon.m4: use proper macro condition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Many thanks to Paul Eggert [EMAIL PROTECTED] who committed the patch to gl_FUNC_MMAP_ANON to check for message, not for MAP_ANON. I have updated the feature branch of CVS on cvshome.org to use the new version of the m4/mmap-anon.m4 file. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCddX+3x41pRYZE/gRAv3bAJ9/5WqErJInzuM9Laa7cnzqvc64wgCgxP4g zK05B1vpndbZmDtttGdmbtc= =4fEN -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] Re: [PATCH] mmap-anon.m4: use proper macro condition
Hi Folks, I have not seen any discussion or commit on this patch suggested by Moriyoshi Koizumi [EMAIL PROTECTED] (originally submitted to the bug-cvs list and forwarded by me) which allows MacOS X (10.2.x and 10.3.x) to properly be able to '#define HAVE_MAP_ANONYMOUS 1' along with '#define MAP_ANONYMOUS MAP_ANON' ... This lets us get rid of the configure lines: cat conftest.$ac_ext _ACEOF /* end confdefs.h. */ #include #include sys/mman.h #ifdef MAP_ANON I cant identify this map. #endif _ACEOF and replace them with cat conftest.$ac_ext _ACEOF /* end confdefs.h. */ #include sys/mman.h #ifdef MAP_ANON I cant identify this map. #endif _ACEOF which at least is valid C code. Please install it in GNULIB. Thanks, -- Mark Index: m4/mmap-anon.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/mmap-anon.m4,v retrieving revision 1.4 diff -u -p -r1.4 mmap-anon.m4 --- m4/mmap-anon.m4 7 Mar 2005 17:29:29 - 1.4 +++ m4/mmap-anon.m4 1 May 2005 14:58:15 - @@ -27,8 +27,8 @@ AC_DEFUN([gl_FUNC_MMAP_ANON], #endif ], [gl_have_mmap_anonymous=yes]) -if test $gl_have_mmap_anonymous = no; then - AC_EGREP_HEADER([MAP_ANON], [ +if test $gl_have_mmap_anonymous != yes; then + AC_EGREP_CPP([I cant identify this map.], [ #include sys/mman.h #ifdef MAP_ANON I cant identify this map. ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Patch for making CommitID configurable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Peter, Jim has already mentioned some things about why the commitid code may be useful. It may be worth noting that CVSNT has had this feature for a long time and moving to adopt it satisfies a minor goal of trying to reduce the separation and entropy between the major CVSNT fork of CVS and the CVS that cvshome offers. I honestly do not think this feature is the problem you seem to believe. If you can provide more consumers of the ,v files that have problems using the addition to the format, it would be good to have that list. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCb2ec3x41pRYZE/gRAp6bAJwMvLXXweGhcUaZIYBVz6gP8Z4bxQCg1Zhq 2KS2OFODqpy57sEaGRUnkhE= =wZpp -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Patch for making CommitID configurable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Backes [EMAIL PROTECTED] writes:
On 27 Apr 2005 at 3:21, Mark D. Baushke wrote:
It may be worth noting that CVSNT has had this feature for a long time
and moving to adopt it satisfies a minor goal of trying to reduce the
separation and entropy between the major CVSNT fork of CVS and the CVS
that cvshome offers.
I agree that a commit ID might be a handy feature, but the way CVSNT
did it was merely a quick and dirty hack IMO. It relies on the
concept of seconds since epoch, which is not portable. Further the
commit ID can only be assumed to be unique for a certain repository,
so the whole thing cannot be used if somebody wants to build a
distributed SCM on top of CVS.
The currently generated global_session_id is indeed ((2*sizeof(int)) + 12)
bytes in size and on most platforms that will be 16 bytes. However, the
CVSNT specification says that it may be
global_session_id = Xasprintf (%x%08lx%04x, (int)getpid(),
(long)time (NULL), rand()0x);
Concerning the CVSNT sources...
One 'bug' is that src/RepositoryDatabase.cpp uses
'commitid CHAR(16) not null,' and the CVSNT sources use
src/cvs.h:#define GLOBAL_SESSION_ID_LENGTH 64
src/cvs.h:extern char global_session_id[GLOBAL_SESSION_ID_LENGTH];
doc/cvs.dbk:
primaryCOMMITID, internal variable/primary
/indextermUnique Session ID of cvsnt process. This is a random
string of printable characters that may be up to 256 characters
src/main.cpp
static void make_session_id()
{
sprintf(global_session_id,%x%08lx%04x,(int)getpid(),(long)time(NULL),rand()0x);
}
which means that it is possible for CVSNT to handle 63 bytes in the
global_session_id plus the '\0' byte or for display purposes they
document a 256 character limit.
Of course, at present both CVS and CVSNT are only using [a-fA-F0-9] for
the characters in the string although CVS allows for [a-zA-Z0-9] in our
sanity.sh testing and CVS does not used a fixed buffer length so we
could easilty increase the size of the formulation if there is a need.
We are restricting the use of a '.' in the commitid, but we could
probably relax the encoding to allow a '%' sign and use a %2e escape
if you wanted to add in a FQDN for the hostname.
If there are any other suggestions for how the global_session_id should
be modified, I would like to see it discussed.
I stick to my opinion that currently loginfo provides a much better
way to achieve what Jim sees CommitID useful for.
Are there any other folks that wish to chime in on this discussion?
I honestly do not think this feature is the problem you seem to believe.
Even if it isn't, I don't see why it shouldn't be possible to apply
my patch to let the user decide what he wants. What is currently
being done is that users are forced to have CommitIDs even if they
don't want them (for whatever reason). This cannot be right.
Hmmm... cvs 1.12.x is where we are doing new features that we consider
to be reasonable as the future direction of CVS. It is not yet the
stable version. If possible, when this version is blessed as STABLE to
replace the cvs 1.11.x series, we would rather have a standard version
that interoperates well with all other clients and servers.
If other people believe strongly that this feature needs to be a
compile-time or pre-repository config option, we can consider it and
bring it to a vote among the developers based on user input.
For example, I am waiting to hear what Greg A. Woods has to say on this
subject. He has been fairly vocal in the past about retaining the older
RCS ,v format without extension.
If you can provide more consumers of the ,v files that have problems
using the addition to the format, it would be good to have that list.
Besides rcs, I only remember cvsup as a program that might access the
files in a CVS directory directly. However, I don't know if it has
any problems with the addition to the format, as I don't use it.
Yes. I know about CVSup and CVSupd. I believe that it handles
newphrases in the tree section of the delta without any problems. See
RCSDelta.m3 IterateTextPhrases and IterateTreePhrases. It just walks
them in order and preserves them.
So, to be clear, the following are potential consumers of additions:
RCS - the format allows for newphrases and RCS has a -q switch to
inhibit complaints about it not understanding how to use the
newphrase it does not recognize.
CVS - cvs 1.12.x has introduced commitid into the delta structure
CVSNT - The original home of the commitid allowed for a 64byte
buffer on generation and documents in cvs.dbk that it may be
up to 256 characters long.
CVSup - seems to handle RCS extensions without caring what they do.
There are a number of tools and utilities that use RCS which may have
problems:
ViewCVS
CVSWeb
SmartCVS
TortoiseCVS
but I
Re: Patch for making CommitID configurable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Just a note, I already agreed to commit Peter's patch some days ago in this thread, with the change that I was going to make the default behavior leaving commitID enabled, with his config key able to turn it off, pending lack of objections from the other developers and general agreement from users. Hmmm... I don't think that would avoid having some commitid deltas in the repository if the user wants to make use of the switch. I was under the impression that Peter's patch adds a new UseCommitID keyword into the CVSROOT/config file. This file has an initial creation via 'cvs init' and will not have a commitid in the delta right now (I have been meaning to ask if that is a bug or a feature). If an administrator goes ahead and modifies a checked-out copy of CVSROOT/config to add UseCommitID=no and commits it, then the delta for that change will have a commitid in it. If the intent of the administrator was to avoid having ANY deltas in the repository with the commitid newphrase, then this one file will be an exception. So, if you wish to default to UseCommitID=yes for CVS, then you probably also need to provide a 'cvs admin' switch that will remove commitid phrases for given revisions of files. Is avoiding commitid really worth all of this trouble? If so, then allowing the administrator to rip out any uses of it after the fact also seems needed. Comments on the patch... if UseCommitID=no I would have expected that to just deal with the generation of new commitid keywords, not the display of log messages or versions that have it. So, I would have expected it to control import.c and rcs.c output, but I would NOT have expected it to be quiet if it finds a commitid field present in the delta. I would also expect that the new .commitid tag processing would work if there were delta records with a commitid in them regardless of the UseCommitID value. Summary: I can see the (marginal) utility of adding a way to avoid creating new commitid tags in the RCS files of the CVS repository. I can not see any benefit in supressing new CVS functionality for revisions of files that use them. Therefore, I object to Peter's patch as provided. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCb+iZ3x41pRYZE/gRAiNRAKCEz0zm80/FNdGTx+LmgKSYUTTqzQCeOv9S KteQb5obhzNsKqWzHjplWE4= =zJKj -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Patch for making CommitID configurable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Backes [EMAIL PROTECTED] writes: On 27 Apr 2005 at 11:08, Mark D. Baushke wrote: global_session_id = Xasprintf (%x%08lx%04x, (int)getpid(), (long)time (NULL), rand()0x); (long)time(NULL), getpid(): not portable. That one requires supporting documentation. Which platforms do not provide them? CVSNT and CVS both use them extensively across all of our supported platforms. I will grant that time() may eventually (in 2036) need to be revisited when the UNIX epoch wraps. I would support 64bit time if there were an easy way to specify it. On some sytems, truncating getpid() to an int may be less useful if sizeof(pid_t) is larger than sizeof(int). If you know of any such systems, we could consider going to a larger type for the Xasprintf() call. rand()0x: makes commit IDs probabilistic, not unique. True enough. Why not simply keep a counter in a file which is being increased on each commit and used as the commit ID? This avoids the probabilistic aspect and is entirely portable. It was also the solution used for rcsfreeze. The location could be a config file option. This would create a hot-spot for contention of all cvs commits for the repository in very large and very busy repositories this would be a nightmare. If you want a 'better' global_session_id, then perhaps doing a SHA256 hash of all of the files being committed in this session would be more unique... of course, that is problematic for other reasons. We are restricting the use of a '.' in the commitid, but we could probably relax the encoding to allow a '%' sign and use a %2e escape if you wanted to add in a FQDN for the hostname. What is the reason for '.' being disallowed? See the discussion on being able to use a commitid in a CVS tag in the archives. CVS has added stuff to the RCS format in the past, even though those options are usually disabled: permissions and hardlinks. I would love to see any new feature adding to the RCS file format being handled in exactly the same way. The same way as your optional CVSROOT/config addition with it disabled by default? CVSNT has added commitid and mergepoint newphrases. It is entirely possible that CVS could add support for a mergepoint newphrase in some future release. CVSNT has also extended the -k flags to allow for UTF-8 characters. I guess -k and mergepoint are only being written on user request. (for example if he sets the new keyword or if he requests a mergepoint to be written explicitely.) This is entirely okay. The difference is that commitid is being written on each commit, while it was not like that in the past, and currently in a way that does not allow the user to prevent that. It happens when users do a 'cvs update -j branch-tag' command. See http://www.cvsnt.org/wiki/MergePoint for details. So, it is not really very explicit on the part of the user in some sense. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCb+x53x41pRYZE/gRAsscAJ94JZEx8WeLzfhh5Gnib51xFHcqggCggnwh +7sEjFcPwO5tigU8ASEjZWY= =gnOD -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: history and val-tags locks.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: I'm getting ready to make two changes, possibly on stable. The first would be to add file locking for the CVSROOT/history and CVSROOT/val-tags files. I have some reports of massively corrupted history files in large repositories, and I don't see any other likely cause. Similarly, I expect locking will also be necessary on val-tags in such a large repository and the additional code will be minimal after I add the history locking stuff. I was thinking that I would make totally separate lock dirs for this (#cvs.history.lock and #cvs.val-tags.lock or somesuch) to allow concurrent write access to other CVSROOT files, history, and val-tags. I don't think deadlock will be an issue - despite the fact that any given process writing to the history file or val-tags might hold any number of other locks, the history or val-tags lock will always be last in the chain and only held for the duration of the write of a single line to the file. Does anyone see any problems with that design? Since file corruption is the current consequence of not having these locks, I thought this would be justified on stable. Any objections? I have no objections. (I have seen such corrptions and as a result have reduced the amount of history being logged in favor of custom hacks using syslog().) The other set of changes I was considering would be to enable a number of new keywords for the config file to allow CVS to search for config files in new locations. I would not be changing the default locations, but the new setup would enable something like the following to be specified in CVSROOT/config: CheckoutListFile $CVSROOT/CVSROOT/admin/checkoutlist CommitInfoFile$CVSROOT/CVSROOT/triggers/commitinfo CVSIgnoreFile $CVSROOT/CVSROOT/cvsignore CVSWrappersFile $CVSROOT/CVSROOT/admin/cvswrappers EditInfoFile $CVSROOT/CVSROOT/triggers/editinfo HistoryFile $CVSROOT/CVSROOT/logs/history/%Y%m%d HistorySearch $CVSROOT/CVSROOT/logs/history/* LogInfoFile $CVSROOT/CVSROOT/triggers/loginfo ModulesFile $CVSROOT/CVSROOT/modules NotifyFile$CVSROOT/CVSROOT/triggers/notify PasswdFile$CVSROOT/CVSROOT/admin/passwd RCSInfoFile $CVSROOT/CVSROOT/triggers/rcsinfo ReadersFile $CVSROOT/CVSROOT/admin/readers TagInfoFile $CVSROOT/CVSROOT/triggers/taginfo ValTagsFile $CVSROOT/CVSROOT/admin/val-tags VerifyMsgFile $CVSROOT/CVSROOT/triggers/verifymsg WritersFile $CVSROOT/CVSROOT/admin/writers Please do not break the assumption of keyword=value in the CVSROOT/config file. So, the above would need to look closer to this: CheckoutListFile=$CVSROOT/CVSROOT/admin/checkoutlist CommitInfoFile=$CVSROOT/CVSROOT/triggers/commitinfo CVSIgnoreFile=$CVSROOT/CVSROOT/cvsignore CVSWrappersFile=$CVSROOT/CVSROOT/admin/cvswrappers EditInfoFile=$CVSROOT/CVSROOT/triggers/editinfo HistoryFile=$CVSROOT/CVSROOT/logs/history/%Y%m%d HistorySearch=$CVSROOT/CVSROOT/logs/history/* LogInfoFile=$CVSROOT/CVSROOT/triggers/loginfo ModulesFile=$CVSROOT/CVSROOT/modules NotifyFile=$CVSROOT/CVSROOT/triggers/notify PasswdFile=$CVSROOT/CVSROOT/admin/passwd RCSInfoFile=$CVSROOT/CVSROOT/triggers/rcsinfo ReadersFile=$CVSROOT/CVSROOT/admin/readers TagInfoFile=$CVSROOT/CVSROOT/triggers/taginfo ValTagsFile=$CVSROOT/CVSROOT/admin/val-tags VerifyMsgFile=$CVSROOT/CVSROOT/triggers/verifymsg WritersFile=$CVSROOT/CVSROOT/admin/writers Am I correct in assuming that this change also assumes handling expansions of internal CVS variables like $CVSROOT is being added to to CVSROOT/config processing and that those are NOT general purpose environment variables being added? Note that HistoryFile has an argument that would basically be run through strftime, to enable log rotation. Also see the HistorySearch, which would be used as a file glob to locate history files to be read for executions of the `cvs history' command. Hmmm I do not like the BSD glob(3) function and its introduction in CVS would not make sense given we already have POSIX fnmatch() available... It would be better to specify looking for history files in terms of fnmatch() semantics if that is what you intend to use to do the resolution. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCb+/Q3x41pRYZE/gRArfHAJ9atipXM5i0NRCQDrvyEXUlFv0o0ACgkoQ5 wJrHwWL2uAcNG/pwJqgmHc8= =wyUH -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: history and val-tags locks.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Derek Price [EMAIL PROTECTED] writes: I won't. My apologies for cutting and pasting the list above out of context from an email I received. Good, sorry for sounding alarmist. :-) Am I correct in assuming that this change also assumes handling expansions of internal CVS variables like $CVSROOT is being added to to CVSROOT/config processing and that those are NOT general purpose environment variables being added? Yes. I'll probably hook into the same function used to do this by the trigger scripts, expand_path(). This should enable the same config file to be used in multiple CVS roots as well. This sounds reasonable to me. An associated change I was putting off talking about was adding a global `-c config_file' option to cause CVS to look elsewhere for its configuration file. I worry about the security implications of this one. I don't believe it can be allowed for anythiner other than :pserver: mode where the administrator takes care of arguments to the cvs executable directly. If the user may provide a config file that specifies the commitinfo triggers to use, it could subvert the intention of the repository administrator. The administrator could get the same effect by putting a symbolic link into CVSROOT for the config file... of course, it would be well to ensure that rebuilding the repository database would not destroy that link. That is what I meant. I had thought that a file glob was not precise and referred to a whole class of path expansion, using patterns like name.??.* , and implemented by various functions including fnmatch. I use the term in the same way I might specify regex matching when I don't see a need to be more precise (e.g. basic regex, extended regex, perl regex, etc.). I completely intended and continue to intend to use the POSIX fnmatch() we've already imported from GNULIB to implement this matching and any similar matching in the future. Good. (I was just trying to be very clear and not misrepresent your intention.) -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCcAWH3x41pRYZE/gRAtlWAKC2HoNtPj7aY8w/BHIisfEqU6lE3QCg2OU2 OwbgnsvZJaAt+rudYSHcxPc= =lVJk -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Patch for making CommitID configurable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Peter Backes wrote:
On 21 Apr 2005 at 10:02, Derek Price wrote:
I really want to make this the default behavior, even after an
upgrade. Would this do the trick for you?
What do you mean exactly? new-use_commit_id = true instead of
false, i.e. have commit IDs written even for old repositories after
an update? I'd not recommend this. It violates the principle of
least astonishment (like the current solution). However, at least it
was better than the current situation.
I'm not sure I believe that. I think most people would prefer to not
have to jump through any hoops to see new features enabled, especially
when dealing with feature releases, and I don't think all that many
people run RCS inside their CVS repositories anymore. Any dissenting
opinions other than Peter's out there?
I am given to understand that WebCVS and ViewCVS can run 'rcs' commands
like rlog as a way to glean information out of the local repository
without running 'cvs' commands on the ,v files.
Why is RCS whining anyhow? The spec leaves room for newphrases. Is it
requesting an upgrade?
If you pass the -q switch to the RCS 5.7 commands, they will not whine
about unknown phrases. The warning message spews from the
rcs-5.7/src/rcslex.c::warnignore() function which is called from
rcs-5.7/src/rcslex.c::getphrases() when NextString is not one of the
known keywords.
A solution would be to ensure that the '-q' switch is being passed to
any rcs command that might run into a newphrase like 'commitid'
% rlog foo,v
rlog: foo,v: warning: Unknown phrases like `commitid ...;' are present.
...
% rcsdiff -r1.1 -r1.2 foo,v
rcsdiff: foo,v: warning: Unknown phrases like `newphrase ...;' are present.
===
RCS file: foo,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
26a27
#
%
See also the threads here:
http://www.cvsnt.org/pipermail/cvsnt/2003-February/005206.html
http://mailman.lyra.org/pipermail/viewcvs/2003q1/001713.html
http://www.akhphd.au.dk/~bertho/cvsgraph/viewcvs.cgi/cvsgraph/rcsl.l?rev=1.6
One solution might be to modify lib/vclib/bincvs/__init__.py to
use commands like 'co', 'rlog' with different command-line args than
fp = self.rcs_popen('co', (rev_flag, full_name), 'rb')
fp = self.rcs_popen('rlog', args, 'rt', 0)
or the others that exist.
Another alternative might be to provide a patch to the RCS maintainer
to support any of the newphrase formats that CVS has introduced...
Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCbezU3x41pRYZE/gRAq2KAKCg9gtNeRyUVhgA1aSRMlpBL/m1QQCfSHPH
o1NmVR1kyrB/uucNfTBFeTA=
=pUMj
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Patch for making CommitID configurable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: I am given to understand that WebCVS and ViewCVS can run 'rcs' commands like rlog as a way to glean information out of the local repository without running 'cvs' commands on the ,v files. Okay, but the threads you cite seem to indicate that they have dealt with the problems by passing -q into RCS or tweaking their parsers. I still don't see any reason not to enable commitds by default on feature. Okay. I suppose it may be desirable to make note of the possible problems folks might see if they are using older RCS tools in our CVS documentation, but this thread may be useful enough for that purpose. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCbpW73x41pRYZE/gRAv85AKCxmFJru81qiaSDC29xpQV766+AyACZAcpB 6e3Bpt0FAjp/z0nKbnL/+/4= =p81z -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [PATCH] Improve pam header detection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Moriyoshi, I have committed your patch to allow --enable-pm to work on MacOS X to the cvshome.org CVS trunk. Thanks, -- Mark Moriyoshi Koizumi [EMAIL PROTECTED] writes: The second patch is to handle the case where PAM headers are installed in $INCLUDES/pam/ rather than $INCLUDES/security/ . Perhaps I was missing something, but I didn't manage to get it built without this patch on MacOS X, with --enable-pam specified. Hope this helps anyway, too. Regards, Moriyoshi p.s. the patches can be downloaded from http://www.voltex.jp/patches/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCbWaG3x41pRYZE/gRAl2wAKDcTtIWXDiaKV+Hko4W6jd6ItKYPwCfbV1r J5GrIyTdLQ8DdDJiGGp7zdI= =eZJI -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Patch for preserving edit on files when checking out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Darren Bowles wrote: Please find attached my cvs patch, with test added to sanity.sh. As requested, the format is cvs diff -u ... That said, it looks like it will probably work as Darren specified, but I am left with a few general discussion questions: Edits are not attached to a particular workspace. Neither is there a ref count. Perhaps a general solution would maintain an edit ref count so that something like cvs co proj; cvs edit proj/file; cvs co -d proj-new proj; cvs edit proj-new/file; cvs unedit proj/file doesn't remove the edit in the proj -new directory. Hmmm... that seems rather complicated. I'm not sure I should commit Darren's change until we can answer this question, though, on the other hand, I am almost certain Darren's change is a step in the right direction. It certainly doesn't make things any worse. Any other opinions? I have no fundamental objections to Darren's change, but I am also interested in hearing opinions on the matter. Out of curiosity, can someone tell us if CVSNT has solved this problem differently? -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCZ0F63x41pRYZE/gRAkwKAKCmXECeJ01DX8qNZC6qWJKwmg3KNACgkI9h 7rn4rKwW9KNYuvmwiaF9bws= =uzMg -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: get_date returning false
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Ian Abbott wrote: | Hi Derek, | | On 08/04/05 19:05, you wrote: | | Is there some simple, cross-platform test I could use to fall | back on GMT0BST,M3.5.0,M10.5.0 if the Europe/London timezone | isn't defined or skip the tests entirely if neither zone is | enabled? | | | No idea, sorry. Hopefully it won't matter unless the internal use | of GMT creaps back in! Anybody have any idea how many platforms won't support the Large_Place/City timezone format? Mark? Larry? Should I check in some new tests and see how many nightly test platforms break? I could always back them out again. I think most of my platforms will work fine (FreeBSD 4.x, GNU/Linux, Solaris, MacOS X). I am not sure about the CRAY... Let me see: ssh login.cray-cyber.org attach to yel.cray-cyber.org ## # Welcome to yel.cray-cyber.org# # This is a Cray Y/MP EL with 4 CPUs and 1 GB RAM running UNICOS 9.0 # ## # For more information about this machine, see the website # # By logging on, you agree to the terms of usage which can be found # # under http://www.cray-cyber.org/access/terms.php # ## [EMAIL PROTECTED] mdb]$ echo $TZ MET-1MET,M3.5.0,M10.5.0 [EMAIL PROTECTED] mdb]$ export TZ=Asia/Calcutta [EMAIL PROTECTED] mdb]$ date Fri Apr 15 07:01:59 2005 [EMAIL PROTECTED] mdb]$ export TZ=MET-1MET,M3.5.0,M10.5.0 [EMAIL PROTECTED] mdb]$ date Fri Apr 15 09:02:13 MET 2005 [EMAIL PROTECTED] mdb]$ Let me see what the man page for environ has to say about TZ [EMAIL PROTECTED] mdb]$ man -s 7 environ ... TZTime zone information. The format is xxxnzzz where xxx is standard local time zone abbreviation, n is the difference in hours from GMT, and zzz is the abbreviation for the daylight-saving local time zone, if any; for example, EST5EDT. ... [EMAIL PROTECTED] mdb]$ TZ=Pacific/Honolulu date Fri Apr 15 07:07:12 2005 [EMAIL PROTECTED] mdb]$ That said, I doubt if this will be a big problem given that CRAY doesn't yet support client/server as I have only been able to get :local: to work on it. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCX2kX3x41pRYZE/gRAv2OAKDECR+JK1WE/FasJqigHvsvCzklegCeNZDL K893bsLln1IzWscZc8cLK+c= =DJA9 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: get_date returning false
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: [EMAIL PROTECTED] mdb]$ export TZ=Asia/Calcutta [EMAIL PROTECTED] mdb]$ date Fri Apr 15 07:01:59 2005 ... [EMAIL PROTECTED] mdb]$ TZ=Pacific/Honolulu date Fri Apr 15 07:07:12 2005 [EMAIL PROTECTED] mdb]$ That said, I doubt if this will be a big problem given that CRAY doesn't yet support client/server as I have only been able to get :local: to work on it. Hrm. Does the Cray exhibit similar behavior to the following for unrecognized time zones? The POSIX spec doesn't really seem to specify... [EMAIL PROTECTED] ccvs-merge]$ date +%Z EDT [EMAIL PROTECTED] ccvs-merge]$ TZ=Asia/Calcutta date +%Z IST [EMAIL PROTECTED] ccvs-merge]$ TZ=Asia/Garbage date +%Z Asia/Garbage [EMAIL PROTECTED] ccvs-merge]$ I could write a simple test and skip the TZ dependent tests when `TZ=REGION/CITY date +%Z` = REGION/CITY. [EMAIL PROTECTED] mdb]$ date +%Z MET [EMAIL PROTECTED] mdb]$ TZ=Asia/Calcutta date +%Z [EMAIL PROTECTED] mdb]$ TZ=Asia/Garbage date +%Z [EMAIL PROTECTED] mdb]$ AAA=`TZ=Asia/Garbage date +%Z`;echo '$AAA' ' ' [EMAIL PROTECTED] mdb]$ AAA=`TZ=Asia/Calcutta date +%Z` ; echo '$AAA' ' ' [EMAIL PROTECTED] mdb]$ AAA=`TZ=Asia/Calcutta date +%Z` ; echo '$AAA' i [EMAIL PROTECTED] mdb]$ od i 0 023440 020040 023412 6 [EMAIL PROTECTED] mdb]$ AAA=`TZ=Asia/Garbage date +%Z`; echo '$AAA' i [EMAIL PROTECTED] mdb]$ od i 0 023440 020040 023412 6 [EMAIL PROTECTED] mdb]$ AAA=`date +%Z`; echo '$AAA' i [EMAIL PROTECTED] mdb]$ od i 0 023515 042524 023412 6 [EMAIL PROTECTED] mdb]$ cat i 'MET' [EMAIL PROTECTED] mdb]$ uname -a sn5176 sn5176 9.0.2.2 sin.0 CRAY Y-MP [EMAIL PROTECTED] mdb]$ So, for unrecognized zones, three spaces are produced for the timezone on the CRAY Y-MP system. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCX98N3x41pRYZE/gRAnG1AJ9Ic3A1ggXKAzk3tdS1NrokRYGnvACeMEDb 2JIXiXtjIiXZf8w8rNDFAM0= =APyc -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: get_date returning false
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Derek,
Your script arrived here with linewrap problems... after I
fixed them, I get the following results with various boxes
I can access today...
I ran the attached script with three different arguments and
here are the results:
Timezone TestedResult Host (OS Release Hardware)
Asia/Calcutta false AIX 4.3 unknown
Europe/London false AIX 4.3 unknown
Pacific/Honolulu false AIX 4.3 unknown
Asia/Calcutta trueFedora Core release 3 GNU/Linux i686
Europe/London trueFedora Core releaes 3 GNU/Linux i686
Asia/Calcutta trueFreeBSD 4.10-RELEASE-p2 i386
Europe/London trueFreeBSD 4.10-RELEASE-p2 i386
Pacific/Honolulu trueFreeBSD 4.10-RELEASE-p2 i386
Asia/Calcutta trueFreeBSD 4.2-RELEASE i386
Europe/London trueFreeBSD 4.2-RELEASE i386
Pacific/Honolulu trueFreeBSD 4.2-RELEASE i386
Asia/Calcutta trueFreeBSD 5.2-RELEASE i386
Europe/London trueFreeBSD 5.2-RELEASE i386
Pacific/Honolulu trueFreeBSD 5.2-RELEASE i386
Asia/Calcutta trueGentoo 1.4.16 GNU/Linux i686
Europe/London trueGentoo 1.4.16 GNU/Linux i686
Pacific/Honolulu trueGentoo 1.4.16 GNU/Linux i686
Asia/Calcutta false SunOS 5.8 SUNW,Sun-Blade-1000
Europe/London false SunOS 5.8 SUNW,Sun-Blade-1000
Pacific/Honolulu false SunOS 5.8 SUNW,Sun-Blade-1000
Asia/Calcutta false NetBSD 2.99.15 i386
Europe/London false NetBSD 2.99.15 i386
Pacific/Honolulu false NetBSD 2.99.15 i386
Asia/Calcutta false SunOS 5.7 SUNW,UltraSparc-IIi-cEngine
Europe/London false SunOS 5.7 SUNW,UltraSparc-IIi-cEngine
Pacific/Honolulu false SunOS 5.7 SUNW,UltraSparc-IIi-cEngine
Asia/Calcutta trueSunOS 5.9 SUNW,Ultra-80
Europe/London trueSunOS 5.9 SUNW,Ultra-80
Pacific/Honolulu trueSunOS 5.9 SUNW,Ultra-80
Asia/Calcutta false UNICOS 9.0 CRAY Y-MP
Europe/London false UNICOS 9.0 CRAY Y-MP
Pacific/Honolulu false UNICOS 9.0 CRAY Y-MP
Enjoy!
-- Mark
--- tz-test.sh ---
:
# Prep for future calls to valid_timezone().
#
# This should set $UTZ to three spaces, `GMT',
# `Unrecognized/Unrecognized', or possibly the
# empty string, depending on what system we are
# running on. With any luck, this will catch any
# other existing variations as well. The way it is
# used later does have the disadvantage of
# rejecting at least the `Europe/London' timezone
# for half the year when $UTZ gets set to `GMT',
# like happens on NetBSD, but, since I haven't
# come up with any better ideas and since
# rejecting a timezone just causes a few tests to
# be skipped, this will have to do for now.
#
# UTZ stands for Unrecognized Time Zone.
UTZ=`TZ=Unrecognized/Unrecognized date +%Z`
# The following function will return true if $1 is
# a valid timezone. It will return false and set
# $skipreason, otherwise.
#
# Clobbers $NTZ $skipreason.
#
# SUS2 says `date +%Z' will return `no characters'
# if `no timezone is determinable'. It is,
# unfortunately, not very specific about what
# `determinable' means. On GNU/Linux, `date +%Z'
# returns $TZ when $TZ is not recognized. NetBSD
# 1.6.1 determines that an unrecognizable value
# in $TZ really means `GMT'. On Cray, the standard
# is ignored and `date +%Z' returns three spaces
# when $TZ is not recognized. We test for all
# three cases, plus the empty string for good
# measure, though I know of no set of conditions
# which will actually cause `date +%Z' to return
# the empty string SUS2 specifies.
#
# Due to the current nature of this test, this
# will not work for the three-letter zone codes on
# some systems. e.g.:
#
# test `TZ=EST date +%Z` = EST
#
# should, quite correctly, evaluate to true on
# most systems, but:
#
# TZ=Asia/Calcutta date +%Z
#
# would return `IST' on GNU/Linux, and hopefully
# any system which understands the `Asia/Calcutta'
# timezone, and ` ' on Cray. Similarly:
#
# TZ=Doesnt_Exist/Doesnt_Exist date +%Z
#
# returns `Doesnt_Exist/Doesnt_Exist' on GNU/Linux
# and ` ' on Cray.
#
# Unfortunately, the %z date format string (-HHMM
# format time zone) supported by the GNU `date'
# command is not part of any standard I know of
# and, therefore, is probably not portable.
#
valid_timezone ()
{
NTZ=`TZ=$1 date +%Z`
if test $NTZ = $UTZ || test $NTZ = $1; then
skipreason=$1 is not a recognized timezone on this system
return `false`
else
return `:`
fi
}
if valid_timezone ${1+$@}; then
echo valid_timezone ${1+$@} = true
else
echo valid_timezone ${1+$@} = false
fi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCYDp73x41pRYZE/gRAmk8AKDShDDwjjuZpanN7cfpVLJECqmcPACgxdvu
FJs7VStollRoIU/QR+2cgX8=
=CfdJ
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Patch for preserving edit on files when checking out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darren Bowles [EMAIL PROTECTED] writes: Please find attached my CVS patch for preserving editor flag upon multiple checkouts. The patch was not found as bug-cvs@gnu.org strips attachments. You may consider opening an issue on https://cvshome.org if you wish. Or, you may include the patch inline in your message. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCQCKD3x41pRYZE/gRAtcWAKCkv86ga3n1ZI4Dz74w2fdPprOgNwCgswVe 37HsntB+pZluci9U+qLPOWk= =XrCr -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: PATCH: A few validate_repo.pl enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Torsten Martinsen [EMAIL PROTECTED] writes: From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 9:12 PM To: 'Mark D. Baushke'; Torsten Martinsen Cc: bug-cvs@gnu.org Subject: RE: PATCH: A few validate_repo.pl enhancements Mark D. Baushke wrote: Is it reasonable to exclude ';' from the author field? If so, then [^;]+ is probably better than [\S\s]+, if not then .+ is probably better. I'd say it's reasonable, considering that semicolons are used to indicate the end of the field. Unless... are there systems that allow or even require semicolons in user names? I wouldn't be surprised if Windows allowed it, but I haven't tried it. IMHO, since allowing ';' would probably break a lot of other stuff, [^;]+ is a superior solution. Agreed. Patch commited. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCNVB53x41pRYZE/gRAu0PAKC3AeOe66NEAfk+WrP1RdPD/6YOHACgzvvS l5dnNBGOnshj2srgCVkMVcA= =r9U3 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: PATCH: A few validate_repo.pl enhancements
Torsten Martinsen [EMAIL PROTECTED] writes:
This patch fixes two minor problems in the validate_repo.pl script:
Your patch was line wrapped. You might wish to disable line wrap when
sending patches in future e-mail.
1) User names containing spaces could not be parsed. (Such user names
are relatively common in Windows environments).
Is it reasonable to exclude ';' from the author field? If so, then [^;]+
is probably better than [\S\s]+, if not then .+ is probably better.
2) Perl complains about an unitialized variable being used, which caused
me to get a lot of annoying cron mail :-)
Okay.
A revised patch is provided below. Does this work for you?
-- Mark
2005-03-11 Mark D. Baushke [EMAIL PROTECTED]
* validate_repo.in (get_history): Allow whitespace in the author
field. Avoid uninitialized hash.
(Problem report from Torsten Martinsen [EMAIL PROTECTED].)
--- validate_repo.in.~1.6.~ 2004-10-25 14:19:04.0 -0700
+++ validate_repo.in2005-03-11 11:36:28.127009000 -0800
@@ -496,7 +496,7 @@ sub get_history
if( $ignore == 2 )
{
if( my ( $date, $author, $state ) =
-$line =~ /^date: (\S+ \S+); author: (\S+);
state: (\S+);/ )
+$line =~ /^date: (\S+ \S+); author: ([^;]+);
state: (\S+);/ )
{
$rinfo{$revision} =
{
@@ -700,7 +700,8 @@ sub find_interesting_revisions
|| $max_branch_revision{$branch_number}
$branch_rev );
}
- push( @new_revisions, 1.1 ) unless $max_branch_revision{1} == 1;
+ push( @new_revisions, 1.1 ) unless (exists $max_branch_revision{1}
+ $max_branch_revision{1} == 1);
while( ( $key, $value ) = each ( %max_branch_revision ) )
{
push( @new_revisions, $key . . . $value );
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: In the case where the information came out of the directory CVS/Tag file, it becomes available in vers-nonbranch, but not otherwise. In other cases, the RCS file gets parsed anyhow, but only on the server. Of course, since you need RCS information to resolve these tags anyhow, I expect you are currently only doing so on the server anyhow, whether you realized it or not. Regardless, I am reconsidering the decision to store numerical revision numbers for static tags. Technically, HEAD is really a static tag (it points to a particular set of revision numbers). It just happens to point to the most recent set on the trunk. Therefore, an update might retrieve a new head revision, but a commit will fail, as things stand previous to your patch. I've been assuming that .head would work similarly. Why not .prev and .next too? Even if only to simplify code, why not just leave the sticky tag just as the user specified it? It certainly fulfils the principle of least interference, where the user is allowed to shoot themselves in the foot if they like since they might find some use for a dynamic sticky someday that we didn't imagine. Of course, on the other side of this argument, I am fairly confident that there should not be much use for such a dynamic sticky and, therefore, storing a revision number when BRANCH.prev... is supplied, should follow the principle of least suprise, even if it might make status, log, etc. output slightly less legible. What do others think? Does -r.prev mean anything (is it another way to say -r.base.prev)? If so, there are some kinds of relative sticky tags that would need to be resolved in some way if they are to be made the sticky revision. I have no objections to a cvs checkout -rcvs1-11-x-branch-last-merge.prev ccvs and having the sticky revision in use be updated when the cvs1-11-x-branch-last-merge tag is moved. However, I am not sure I understand how 'cvs update -r.base.prev foo' could work as anything other than a 1.48.4.7.prev as the sticky version for a file where the baseline version for foo was 1.48.4.7. I am also wondering how the datestamp version can generally interact with the new .prev and .next tags... -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCL1es3x41pRYZE/gRAiw+AKCeiMkGxMU6v2jxylYTs3J3oPVoiQCgkPQE MqK3n39/wztXp4QK4Dp6gKw= =PQk4 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Frank Hemer wrote: | a revision on BRANCH's parent. This makes sense when speaking | about individual files, but use of .origin with multiple files | probably deserves some sort of warning to the user that what they | asked for may not make sense. | | | Well, as stated before: All relative tags are _only_ valid for | individual files, not for directories. It doesn't matter where the | relative tag appears in a combined tag. | | If applied on a directory, a warning will be shown complaining | about an invalid tag. And cvs aborts. Hrm. The real strength of the .root tag, at least, is that it makes `cvs diff -rBRANCH.root -rBRANCH' possible. I would hate to go to all this trouble and not get this feature. It's just plain not very useful otherwise. The same tag specs could be useful in a merge. I agree. I would really like a way to replace the idioms cvs tag foo-bp cvs tag -b foo-branch cvs up -r foo-branch .lots of changes and commits cvs diff -rfoo-bp -rfoo-branch with something like: cvs tag -b foo-branch cvs up -r foo-branch .lots of changes and commits cvs diff -rfoo-branch.root -rfoo-branch so that we don't need lots of foo-bp tags in the tree. The possibility of doing something like this: cvs tag -b -rfoo-branch.root foo-redeux-branch to allow the creation of an alternative implementation of modified code based on the same original baseline version as foo-branch would also be interesting. And there is the similar matter of `cvs diff -r.commitid.XXX.prev -r.commitid.XXX'. I thought this sort of request was what got you started on this? Yes, it would be highly desirable to be able to do cvs udpate -j.commitid.XXX -j.commitid.XXX.prev to reverse a particular patch. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCL2q63x41pRYZE/gRAmk9AJ4n+e6RZLChAp4cpIZXSO3SIkoNVgCfRyJs aiIYG3QNNVv1DN1QU7BllGc= =Wi+5 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs admin fails in invalid circumstance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Connors [EMAIL PROTECTED] writes: cvs --version Concurrent Versions System (CVS) 1.12.1 (client/server) I am on a network, and I have my own private repository which I share with no-one. All the ,v files, and the checked out files, are owned by me. There unfortunately happens to be a shared repository on the same network, and hence a cvsadmin group. I only access my repository using local file access, and ssh. Since I have no need to be a member of the shared repository, I am not a cvsadmin member. The repository owner (you) have complete control over what folks in a non-cvsadmin group are able to do. Add a UserAdminOptions=ibcaAeluLUnNmostIqxVk line to your CVSROOT/config file and you should be able to use all of the cvs admin options available without being a cvsadmin group member. Why then, does cvs check to see whether I am a member of cvsadmin, despite me having permissions to the files anyway? Because after a user does a checkin to the repository, they will own all of the files in the repository, so that is not a sufficient guarentee that they are permitted to do administration on the repository. This is a useless security measure, if it is one, because I can either hack cvs myself, or I can simply take to the ,v files with a chainsaw^Weditor. It is not useless as it requires shell access to the repository which is not always granted by all cvs administrators. You can 'hack' cvs yourself by creating your own executable with the ./configure --without-cvs-admin-group or by using your own special group ./configure --with-cvs-admin-group=mygroup if you wish to create your own cvs executable. However, I suggest the administrator of the other repository will be unhappy with you if you use your own cvs executable on the shared repository. Is it just a case of forgetting to turn off the test when accessing over non pserver etc methods? No, it is not. -- Mark For further reading consider the following documentation. https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_16.html#SEC132 https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_18.html#SEC205 UserAdminOptions=value Control what options will be allowed with the cvs admin co section admin--Administration) for users not in the cvsadm value string is a list of single character options which s If a user who is not a member of the cvsadmin group tries cvs admin option which is not listed they will will receiv message reporting that the option is restricted. If no cvsadmin group exists on the server, CVS will ignore UserAdminOptions keyword (see section admin--Administratio When not specified, UserAdminOptions defaults to `k'. In o defaults to allowing users outside of the cvsadmin group t admin command only to change the default keyword expansion As an example, to restrict users not in the cvsadmin group admin to change the default keyword substitution mode, loc unlock revisions, and replace the log message, use `UserAd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCLII+3x41pRYZE/gRAqttAJ9FPHN2O1k4zI7FbFsyLUQvJyd/iACfUEIx 5fE5jsHl3pZs+50ApJk3xx8= =bov2 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Derek Price wrote: | | So probably the expression used should connote this. After some | | consideration, I would vote for '.origin' here. I disagree | with | being meaningless. I often export a project state into a | local | repository, work on it, and when I'm done, move the files | back to | the remote repository's sandbox. During local | development I often | want to compare to the initial version of a | file, and using a | single tag for this is just easy. Granted | there are other ways to | achieve this, but they're not as easy | to handle. | | That's fine for 1.1, but how does this help you for a branch? | You might want to diff against the root, but it doesn't make much | sense to care about the first revision on the branch. | | | Good point. What about resolving '.origin' to the very first | revision of the mainline? I don't have any reason to object to that. On further consideration, why doesn't -r1.1 suffice for what you want to do? Possibly for handling the following conditions... - cvs add foo cvs commit -mnew foo echo newstuff foo \ cvs commit -mupdate foo cvs admin -o1.1 foo .origin == 1.2 after this operation - cvs add foo cvs commit -mnew -r2.1 foo .origin == 2.1 - cvs tag -b foo-branch cvs update -rfoo-branch cvs add foo \ cvs commit -mnew foo In this case, is .origin == 1.1 (dead) or is it not found? - cvs tag -b foo-branch cvs update -rfoo-branch cvs add foo \ cvs commit -mnew foo cvs update -A cvs up -jfoo-branch \ cvs commit -mmerge foo .origin == 1.2 I have no objections to .origin being used for the very first revision of the mainline. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJzbw3x41pRYZE/gRApiNAKC8hOUGy1lvebo27DDnxlXORclf3ACdHabl CAwLIZj9tAonI7HPZGzhEzM= =GtfW -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones [EMAIL PROTECTED] writes: Mark D. Baushke writes: I have no objections to .origin being used for the very first revision of the mainline. Why bother with a special name? Just use .trunk.root. Hmmm... true enough. The .origin modifier is not needed. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJz7i3x41pRYZE/gRAhGOAKCTH43+MaleWMGCDnQnqaB8hkENogCeIlxy MZp0E7grYWDn84dUoMuPUK4= =Tizu -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: I thought Mark was just saying earlier in this thread that .trunk.root, by virtue of .root normally specifying a revision on the parent branch, should refer to the `0' revision? Hmmm... I may be getting confused, I thought .trunk.root.prev would be the `0' revision, but if you are right then .trunk.root.next would be the same as .origin right? As for `0', we probably need to be more consistent about it... for example, the command: cvs rdiff -r0 -r1.1 foo-module/foo-file yeilds a diff against /dev/null of the foo-file while the commands cvs co foo-module cd foo-module cvs diff -r0 -r1.1 foo-file yeilds an error message: 'cvs diff: tag 0 is not in file foo-file' this probably needs to be `fixed' to do something reasonable with `0' for most uses as a phantom revision that exists before the file existed on the branch or trunk. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJ0QA3x41pRYZE/gRAtxLAKDKCpFooWEpuPrQ+QKaZFWKntp8jwCgg/st m5sIT/JB03xZC4SdQDnRBYk= =R37G -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: No. I think 0.next would be an invalid construct, or also return 0. Yeah, you are correct. If you take this off the trunk, this might make more sense: BRANCH.root is on the trunk (or another branch), so BRANCH.root.next would return the revision following the root revision on the parent. For example, 1.2.2.7.root would return 1.2. Since 1.2.next yields 1.3, then 1.2.2.7.root.next should also yield 1.3. Yup. Since there is no revision following on the `0 branch', .trunk.root.next should either also be 0 or be invalid. Agreed. Given that 1.2.2.7.root == 1.2 which is the predicessor revision to the first revision on the branch, and .trunk being on the TRUNK, then .trunk.root is the predicessor revision for the TRUNK also known as `0'. Therefore, I suppose that there could be a need for .origin to be the first revision on TRUNK and .trunk.head to replace HEAD on TRUNK. Looking at a mixture of the modifiers with regard to time... One presumes that '.trunk:2005-03-01 08:00:00 UTC' would be the revision that was committed just before 2005-03-01 08:00:00 UTC. It is less clear how one would specify the .next revision on the TRUNK for that case... -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJ1uH3x41pRYZE/gRAsoZAKCfPuDJHWrt+y3Qtwk2AfGe9inw1ACgyQub /m83ZvvHmEFzVQtDX8fo78k= =2HUw -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: `cvs up -p FILE' does not detect write failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Meyering wrote: | Here's a complete patch, minus the parts that are regenerated via | autoreconf (which I'll check in, too, being careful to use | automake-1.9.3, which is what generated the current Makefile.in | files -- unless we can upgrade to automake-1.9.5 -- quite safe, | IMHO). I generally don't mind keeping as up-to-date as possible with Automake, but I also tend to avoid upping the version we use with CVS more frequently than every few months, just to avoid creating extra work for the other maintainers, unless there is a need for some new feature or a fix for a serious bug. It's been a good 3.5 months since our last AM upgrade, so there shouldn't be much problem going to 1.9.5 now if noone objects. I have no objections to moving to automake-1.9.5. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJ2Gk3x41pRYZE/gRAly3AKCSYizNa8azRgQi2pMT7A5WZavXpACgvQWx 8tOWfrs/nm6Qdzt7GAZJimc= =Xtm8 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: I just have one quibble, with your usage of .root. The CVS manual and other sources use root to refer to what you are referring to as the origin of a branch. The logic being that a branch is always rooted in another branch, so the root refers to the revision actually on the parent branch. Good point. I'm not sure what I would recommend in place of what you are calling the root, but I would like to see .root refer to the revision on the parent branch. I agree. That would be less confusing. Maybe .first should indicate the first revision on a branch? '.first': Will always resolve to the first revision on a branch (1.4.2.6.20.root will resolve to 1.4.2.6.1 [assuming that the *.1 version of this branch has not been deleted]). '.root': Will resolv to .first.prev, meaning the predecessor of the first revision on the branch. '.trunk': The most recently commited revision of the mainline. If I have a file that has always just been imported the file, and it is therefore still using a 'branch 1.1.1;' in the RCS file, the .trunk the most recently imported version (possibly something like 1.1.1.96). If an imported file were modified and committed, the first version might be 1.2 and .trunk would be 1.2 in that case. .trunk.first would usually be version 1.1 unless someone had started that file initially on a branch in which case .trunk.first might be 1.2 where 1.1 was a dead revision. .trunk.first.prev would be 0 as a way of getting a diff between /dev/null and whatever other version was being compared. The above is NOT what Frank has proposed, it is just a possible renaming... The rest of your design looks great so far! I Agree! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJfPO3x41pRYZE/gRAtEHAJ0Y9f8qSd+o6nNMEBg96peLl0hPFQCg4mi/ vgdGOLAzGwu2BO7WM5mVqRY= =GSLO -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Hemer [EMAIL PROTECTED] writes: However I didn't have a better idea. Using .base instead can be similar miss-interpreted since there is BASE. How about replacing '.root' with '.tail', and replacing '.origin' with '.root'? Hmmm... I like replacing '.origin' with '.root' and I agree that .base is too confusing with BASE. I have a mild dislike of '.tail' even though it does have some symmetry with HEAD... (I keep thinking that 'tail file' gives me the latest bits appended to the file.) If you don't like '.first' (mentioned in a previous e-mail), perhaps '.branch' is a another alternative name that could be used as the first revision on the branch? -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCJfXP3x41pRYZE/gRAk/JAJ97BT7DuULnxk/JQekzWDn6xD0tbgCeJLSg p80lIMBfQqQCXaZl/kzz1C0= =TA9V -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: failure to append to .cvspass should always be fatal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Meyering [EMAIL PROTECTED] writes: Hmmm... I wonder if it is possible to come up with a sanity.sh test case for this one? I considered it but, dismissed it as infeasible. Of course, I would be happy to be proved wrong. It might work to use a tool like subterfugue, where you could presumably cause to fail the first write after the open-.cvspass-for-append. But if you try to fill the disk containing .cvspass so that there's enough room to rewrite that file, but not enough to append a few bytes more, it probably won't be reliable. I guess if you really insist, you might be able to do something reasonably portable with expect and gdb. I don't think we need a test for it that urgently as yet. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCI2GO3x41pRYZE/gRAopoAKDVdAhBJ6aO6nPsj7LM2gLqOG2VeQCg0UkP Dmp9J+bjmZy/1N5mxr66+QM= =/zHJ -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: failure to append to .cvspass should always be fatal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jim, Your patch looks good to me. Go ahead and commit it. -- Mark Jim Meyering [EMAIL PROTECTED] writes: When a `login' commands leads to appending to .cvspass, that file is copied to a stream opened on a temporary file, and the new entry is appended. While failing to open or fwrite the temporary file evokes an `error (1, ...', a failed fclose gets only a warning: if ((fp = CVS_FOPEN (passfile, a)) == NULL) error (1, errno, could not open %s for writing, passfile); if (fprintf (fp, /1 %s %s\n, cvsroot_canonical, newpassword) == EOF) error (1, errno, cannot write %s, passfile); if (fclose (fp) 0) error (0, errno, cannot close %s, passfile); Admittedly, it's pretty unlikely that an append would fail in the first place. But if cvs fails for an even less likely fprintf write failure, then it should also fail for an fclose-induced write failure. Since there is no comment explaining the discrepancy, I assume it was an oversight. Here's the fix: 2005-02-27 Jim Meyering [EMAIL PROTECTED] * login.c (password_entry_operation): Exit nonzero when failing to close a just-appended-to .cvspass file. Index: src/login.c === RCS file: /cvs/ccvs/src/login.c,v retrieving revision 1.82 diff -u -p -r1.82 login.c --- src/login.c 1 Feb 2005 22:20:06 - 1.82 +++ src/login.c 27 Feb 2005 10:47:58 - @@ -456,7 +456,7 @@ process: if (fprintf (fp, /1 %s %s\n, cvsroot_canonical, newpassword) == EOF) error (1, errno, cannot write %s, passfile); if (fclose (fp) 0) - error (0, errno, cannot close %s, passfile); + error (1, errno, cannot close %s, passfile); } /* Utter, total, raving paranoia, I know. */ ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCIodW3x41pRYZE/gRAp9+AJwPls35bJCTbdHVcaNLQI20Vc/PqACgtIF1 KgPMdo3rO+ZWAHwxz4Bp9oM= =XMzH -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: seg fault when invalid CVSROOT
Hiroyuki Ikezoe [EMAIL PROTECTED] writes:
Hi,
I found a seg fault when the following
$ cvs -d::[EMAIL PROTECTED]@test.org:/cvs co test
I attach a trivial patch.
Note: Attaching anything in messages to bug-cvs@gnu.org gets stripped at
the list exploder, so we didn't get your trivial patch.
I have applied the patch following my .signature for the problem.
-- Mark
2005-02-26 Mark D. Baushke [EMAIL PROTECTED]
* root.c (parse_cvsroot): Handle another Bad CVSROOT.
* sanity.sh (parseroot-8r): Test for it.
(Problem report from Hiroyuki Ikezoe [EMAIL PROTECTED].)
Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.3109
diff -u -p -r1.3109 ChangeLog
--- src/ChangeLog 26 Feb 2005 14:27:55 - 1.3109
+++ src/ChangeLog 26 Feb 2005 17:38:00 -
@@ -1,3 +1,9 @@
+2005-02-26 Mark D. Baushke [EMAIL PROTECTED]
+
+ * root.c (parse_cvsroot): Handle another Bad CVSROOT.
+ * sanity.sh (parseroot-8r): Test for it.
+ (Problem report from Hiroyuki Ikezoe [EMAIL PROTECTED].)
+
2005-02-26 Derek Price [EMAIL PROTECTED]
* server.c: Include netdb.h with server support. Other reformatting.
Index: src/root.c
===
RCS file: /cvs/ccvs/src/root.c,v
retrieving revision 1.107
diff -u -p -r1.107 root.c
--- src/root.c 24 Feb 2005 22:21:08 - 1.107
+++ src/root.c 26 Feb 2005 17:38:00 -
@@ -529,6 +529,11 @@ parse_cvsroot (const char *root_in)
* Calling strtok again is saved until after parsing the method.
*/
method = strtok (method, ;);
+ if (method == NULL)
+ {
+ error (0, 0, Unknown method (`') in CVSROOT.);
+ goto error_exit;
+ }
#endif /* defined(CLIENT_SUPPORT) || defined (SERVER_SUPPORT) */
/* Now we have an access method -- see if it's valid. */
Index: src/sanity.sh
===
RCS file: /cvs/ccvs/src/sanity.sh,v
retrieving revision 1.1048
diff -u -p -r1.1048 sanity.sh
--- src/sanity.sh 26 Feb 2005 02:29:06 - 1.1048
+++ src/sanity.sh 26 Feb 2005 17:38:01 -
@@ -4958,6 +4958,10 @@ $CPROG \[logout aborted\]: Bad CVSROOT:
$CPROG logout: CVSROOT proxy specification is only valid for gserver and
$CPROG logout: pserver connection methods\.
$CPROG \[logout aborted\]: Bad CVSROOT: \`:local;proxy=localhost:/dev/null'\.
+ CVSROOT=::[EMAIL PROTECTED]@test.org:/cvs
+ dotest_fail parseroot-8r $testcvs -d'$CVSROOT' co test \
+$CPROG checkout: Unknown method (\`') in CVSROOT\.
+$CPROG \[checkout aborted\]: Bad CVSROOT: \`$CVSROOT'\.
fi
dokeep
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: fix xgethostname on OSX [patch]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Neil,
A few points...
1) Please do not use MIME formats in message to
the bug-cvs@gnu.org list.
2) It seems that the patch you sent was stripped
by the list software on gnu.org (normally it
throws away attachments of any kind).
3) The lib/xgethostname.c file is maintained in
the GNULIB project. The appropriate place to
report bugs is [EMAIL PROTECTED] a web page
http://www.gnu.org/software/gnulib/ has the
guidelines for this project.
I am adding [EMAIL PROTECTED] to this message so
that they see a description of your problem. They
may wish to consider an MacOSX change even without
the patch your message to bug-cvs@gnu.org was
missing.
Neil Conway [EMAIL PROTECTED] writes:
The attached one-liner fixes a bug in xgethostname on OSX. It appears
that gethostname() on OSX will return ENOMEM via errno if the buffer
that was passed is not sufficiently large to hold the hostname (although
this isn't documented in the gethostname(3) OSX manpage). The
implementation of xgethostname only expects ENAMETOOLONG or EINVAL to be
returned in this case, so xgethostname bails out and returns NULL. Since
CVS doesn't check the return value of xgethostname() (!), this can
result in various badness later on (e.g. invoking strlen() on a NULL
pointer, which was how I ran into this -- the hostname on my system
happens to be the initial xgethostname() buffer size).
The attached patch (against cvs 1.12.11) improves xgethostname() to
check for ENOMEM as well as ENAMETOOLONG and EINVAL. I grant permission
to distribute this patch under the terms of the GNU Public License.
Please apply.
BTW, I think there is still room for improvement:
(a) this behavior is not well-standardized. POSIX claims the hostname
will be truncated if it is larger than the passed-in buffer length (and
it is undefined whether the return value will be NUL terminated), but
AFAICS most systems return an error in this case. It seems glibc 2.1
will return EINVAL, glibc = 2.1 and FreeBSD will return ENAMETOOLONG,
and other systems may well return other errors. It is unnecessary to
rely on this behavior, anyway: why not just make the buffer size
HOST_NAME_MAX or MAXHOSTNAMELEN (etc.) to begin with? It seems silly to
go through this kind of trouble to avoid the allocation of a few hundred
bytes of memory.
I will leave that for the GNULIB maintainers to consider.
For now, you could add something like
#define INITIAL_HOSTNAME_LENGTH 256
to the generated config.h file so that you didn't
have to modify any of the canonical sources...
(b) not checking the return value of xgethostname() is fragile.
Yes, we should fix that problem in the CVS sources.
Would it make sense to fallback to localhost as the hostname if
xgethostname () returns NULL (in addition to printing an error)?
Index: main.c
===
RCS file: /cvs/ccvs/src/main.c,v
retrieving revision 1.237
diff -u -p -u -p -r1.237 main.c
- --- main.c1 Feb 2005 22:20:06 - 1.237
+++ main.c 20 Feb 2005 15:00:07 -
@@ -810,7 +810,14 @@ cause intermittent sandbox corruption.)
/* make sure we clean up on error */
signals_register (main_cleanup);
- - hostname = xgethostname();
+ hostname = xgethostname ();
+ if (hostname == NULL)
+ {
+error (0, errno,
+ xgethostname () returned NULL, using \localhost\);
+hostname = xstrdup (localhost);
+
+ }
#ifdef SERVER_SUPPORT
/* Keep track of this separately since the client can change the
* hostname.
or do folks have a better suggestion?
-- Mark
-Neil
2005-02-21 Neil Conway [EMAIL PROTECTED]
* lib/xgethostname.c: Check for ENOMEM, which is returned by
OSX/Darwin if the specified buffer is not large enough for the
hostname.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCGKiv3x41pRYZE/gRAv8CAJ9JVgQyDbY9IVVAlexaURe3iDv3mwCcD6Ji
YTRDYpf/Qt14H+H3CA1JBa4=
=PDay
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
Larry Jones [EMAIL PROTECTED] writes: Mark D. Baushke writes: All I know for sure is that not having the getc() can cause hangs and removing it can cause a cpu to loop forever, so something needs to be done to fix this. Eh? How can not having it cause hangs? Or did you just get that backwards and mean that having it causes hangs and not having it causes loops? Oops, yes, I had it backwards. Sorry about the confusion. In either case, I believe the loop is a separate problem that I checked in a fix for back on 2002-10-04. Hmmm... was that the change to server.c server_cleanup and server or something else? -- Mark ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
Derek Robert Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Subject: Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix To: [EMAIL PROTECTED] (Derek Robert Price) Date: Thu, 26 Sep 2002 16:07:18 -0400 (EDT) Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Larry Jones) Derek Robert Price writes: Can you suggest an alternative to get around the blocking problem? It looks to me like we're just screwed. The problem is that when old clients use compression, they don't actually close the connection to the server until after the server closes its connection to them. The old server didn't check for EOF on the input stream before closing it, so it didn't matter, but the new server does and thus hangs. Yes, that seems to be the case. However, I see have very little hope that everyone will be updated to cvs 1.11.2 right away... The CVS protocol is set up so that the CVS client and server exchange a list of supported-requests. What if, and I'll have to review the protocol to figure out exactly which request this should be done with, but what if one of the requests that is sent every time has its name changed. Or better yet, clients version 1.11.2 and later send a new protocol string that says I'll close compressed connections. Then the server can use the old method when it doesn't recieve that command and the new when it does. This sounds like a promising path toward resolution. Alternatively, there must be a way to install a 30 second timeout or something around that call to getc(). That might be a useful thing to do in any case. All I know for sure is that not having the getc() can cause hangs and removing it can cause a cpu to loop forever, so something needs to be done to fix this. Thanks, -- Mark ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
Subject: Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix To: [EMAIL PROTECTED] (Derek Robert Price) Date: Thu, 26 Sep 2002 16:07:18 -0400 (EDT) Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Larry Jones) Derek Robert Price writes: Can you suggest an alternative to get around the blocking problem? It looks to me like we're just screwed. The problem is that when old clients use compression, they don't actually close the connection to the server until after the server closes its connection to them. The old server didn't check for EOF on the input stream before closing it, so it didn't matter, but the new server does and thus hangs. Yes, that seems to be the case. However, I see have very little hope that everyone will be updated to cvs 1.11.2 right away... I think our best course of action is to just remove the EOF check from the input buffer case in stdio_buffer_shutdown(), which was the originally suggested fix. I don't like it, the old client behavior is clearly wrong, but I think it's the lesser of two evils. Thank you for the analysis. When do you think this commit will occur to the cvshome.org repository? By the way, it looks to me like the two if (server_active)s in that code should actually be if (!server_active)s, no? Hmmm... I was under the impression that current_parsed_root-hostname was only filled in for the client-side of the transaction. If true, then the two if (server_active)s are likely correct as the are. -Larry Jones Thanks, -- Mark ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
cvs 1.11.2 src/client.c bugfix
Hi Folks,
The following bug report
http://www.freebsd.org/cgi/query-pr.cgi?pr=40227
describes a problem with new files and cvs update. The patch looks good
to me and I would like to see it put into the cvshome.org sources.
Thanks,
-- Mark
FreeBSD log:
revision 1.7
date: 2002/07/08 10:05:26; author: fenner; state: Exp; lines: +3 -2
Always upload new files, even if the timestamps match. This is a workaround
for the trouble that DES and I had with MFCs: when cvs update -jfoo -jbar
creates a new file, it sets the version to 0 (new) but sets the timestamp
in the Entries file to the timestamp of the file that's new on the branch.
The CVS client doesn't upload files whose timestamps match with the Entries
file, so these new files don't get uploaded to the server and the server
fails when trying to check them in.
PR: bin/40227
Approved by:peter
MFC after: 2 weeks
Index:src/client.c
===
RCS file: /cvs/ccvs/src/client.c,v
retrieving revision 1.313
diff -u -p -r1.313 client.c
--- client.c23 Sep 2002 22:11:26 - 1.313
+++ client.c24 Sep 2002 09:08:34 -
@@ -5236,7 +5236,8 @@ warning: ignoring -k options due to serv
}
else if (vers-ts_rcs == NULL
|| args-force
-|| strcmp (vers-ts_user, vers-ts_rcs) != 0)
+|| strcmp (vers-ts_user, vers-ts_rcs) != 0
+|| (vers-vn_user *vers-vn_user == '0'))
{
if (args-no_contents
supported_request (Is-modified))
___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
Hi Derek,
I suspect this patch needs to get into current cvs sources.
(It is in the FreeBSD top-of-tree sources already.)
I can file this as a bug report if you wish...
Thanks,
-- Mark
[EMAIL PROTECTED]
FreeBSD Log:
date: 2002/09/02 07:58:04; author: peter; state: Exp; lines: +627 -17
Fix a cvs server bug introduced in 1.11.2, in the words of the author:
---
Fix communication hanging in communication shutdown phase, caused by at
least older CVS clients (version 1.11.2) and a semantically incorrect
usage of getc() by the server.
---
getc() was being used on a blocking socket/pipe.
Submitted by: rse
Index:src/buffer.c
===
RCS file: /cvs/ccvs/src/buffer.c,v
retrieving revision 1.19
diff -u -p -r1.19 buffer.c
--- buffer.c20 May 2002 18:27:55 - 1.19
+++ buffer.c24 Sep 2002 06:54:01 -
@@ -1392,8 +1392,7 @@ stdio_buffer_shutdown (buf)
if (buf-input)
{
- if (! buf_empty_p (buf)
- || getc (bc-fp) != EOF)
+ if (! buf_empty_p (buf))
{
# ifdef SERVER_SUPPORT
if (server_active)
___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
typo bugfix for ccvs/contrib/man/cvsbug.8
Spelling correction. -- Mark Index: cvsbug.8 === RCS file: /cvs/ccvs/man/cvsbug.8,v retrieving revision 1.4 diff -u -p -r1.4 cvsbug.8 --- cvsbug.829 Nov 1999 20:26:02 - 1.4 +++ cvsbug.827 Nov 2001 10:36:29 - @@ -180,7 +180,7 @@ describe only with each problem report. .IP \(bu 3m For follow-up mail, use the same subject line as the one in the automatic -acknowledgent. It consists of category, PR number and the original synopsis +acknowledgement. It consists of category, PR number and the original synopsis line. This allows the support site to relate several mail messages to a particular PR and to record them automatically. .IP \(bu 3m ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
