Re: history and val-tags locks.

2005-05-18 Thread Mark D. Baushke
-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.

2005-05-18 Thread Mark D. Baushke
-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

2005-05-10 Thread Mark D. Baushke
-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.

2005-05-09 Thread Mark D. Baushke
-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

2005-05-09 Thread Mark D. Baushke
-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.

2005-05-08 Thread Mark D. Baushke
-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.

2005-05-07 Thread Mark D. Baushke
Hi Jim,

Okay. Thanks for the clue. I have committed the patch given after my
.signature in hopes that it will be closer.

I think your patch still had some problems. I believe you need to quote
file names that contain a - character, the dep file for dup-safer
needed to make note of a few other files and the libcvs.mak needed to
learn how to build both dup-safer.obj as well as fd-safer.obj

Thanks,
-- Mark

Index: ChangeLog
===
RCS file: /cvs/ccvs/lib/ChangeLog,v
retrieving revision 1.416
retrieving revision 1.418
diff -u -p -r1.416 -r1.418
--- ChangeLog   3 May 2005 14:59:34 -   1.416
+++ ChangeLog   7 May 2005 08:07:13 -   1.418
@@ -1,3 +1,9 @@
+2005-05-07  Mark D. Baushke  [EMAIL PROTECTED]
+
+   * libcvs.dep: Use a relative path for unistd-safer.h.
+
+   * libcvs.dsp: Update from GNULIB.
+   Add files dup-safer.c, fd-safer.c, and unistd-safer.h.
+   * libcvs.dep, libcvs.mak: Regenerate.
+
 2005-05-03  Derek Price  [EMAIL PROTECTED]
Index: lib/libcvs.dep
===
RCS file: /cvs/ccvs/lib/libcvs.dep,v
retrieving revision 1.19
diff -u -p -r1.19 libcvs.dep
--- lib/libcvs.dep  8 Mar 2005 05:16:29 -   1.20
+++ lib/libcvs.dep  7 May 2005 08:01:35 -
@@ -34,12 +34,27 @@
.\xalloc.h\

 
+.\dup-safer.c : \
+   ..\windows-NT\config.h\
+   ..\windows-NT\stdbool.h\
+   ..\windows-NT\unistd.h\
+   ..\windows-NT\unistd-safer.h\
+   
+
 .\exitfail.c : \
..\windows-NT\config.h\
.\exit.h\
.\exitfail.h\

 
+.\fd-safer.c : \
+   ..\windows-NT\config.h\
+   ..\windows-NT\stdbool.h\
+   ..\windows-NT\unistd.h\
+   ..\windows-NT\unistd-safer.h\
+   .\error.h\
+   
+
 .\fncase.c : \
..\windows-NT\config.h\
..\windows-NT\ndir.h\
Index: lib/libcvs.dsp
===
RCS file: /cvs/ccvs/lib/libcvs.dsp,v
retrieving revision 1.20
diff -u -p -r1.20 libcvs.dsp
--- lib/libcvs.dsp  8 Mar 2005 05:16:29 -   1.20
+++ lib/libcvs.dsp  7 May 2005 08:01:35 -
@@ -105,10 +105,18 @@ SOURCE=.\dirname.c
 # End Source File
 # Begin Source File
 
+SOURCE=.\dup-safer.c
+# End Source File
+# Begin Source File
+
 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
@@ -478,6 +486,10 @@ SOURCE=..\windows-NT\unistd.h
 # End Source File
 # Begin Source File
 
+SOURCE=..\windows-NT\unistd-safer.h
+# End Source File
+# Begin Source File
+
 SOURCE=.\unlocked-io.h
 # End Source File
 # Begin Source File
Index: lib/libcvs.mak
===
RCS file: /cvs/ccvs/lib/libcvs.mak,v
retrieving revision 1.21
diff -u -p -r1.21 libcvs.mak
--- lib/libcvs.mak  8 Mar 2005 05:16:29 -   1.21
+++ lib/libcvs.mak  7 May 2005 08:01:35 -
@@ -45,7 +45,9 @@ CLEAN :
[EMAIL PROTECTED] $(INTDIR)\basename.obj
[EMAIL PROTECTED] $(INTDIR)\closeout.obj
[EMAIL PROTECTED] $(INTDIR)\dirname.obj
+   [EMAIL PROTECTED] $(INTDIR)\dup-safer.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
@@ -101,8 +103,10 @@ LIB32_OBJS= \
$(INTDIR)\asnprintf.obj \
$(INTDIR)\basename.obj \
$(INTDIR)\dirname.obj \
+   $(INTDIR)\dup-safer.obj \
$(INTDIR)\exitfail.obj \
$(INTDIR)\fncase.obj \
+   $(INTDIR)\fd-safer.obj \
$(INTDIR)\fnmatch.obj \
$(INTDIR)\fseeko.obj \
$(INTDIR)\ftello.obj \
@@ -162,7 +166,9 @@ CLEAN :
[EMAIL PROTECTED] $(INTDIR)\basename.obj
[EMAIL PROTECTED] $(INTDIR)\closeout.obj
[EMAIL PROTECTED] $(INTDIR)\dirname.obj
+   [EMAIL PROTECTED] $(INTDIR)\dup-safer.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
@@ -216,7 +222,9 @@ LIB32_OBJS= \
$(INTDIR)\asnprintf.obj \
$(INTDIR)\basename.obj \
$(INTDIR)\dirname.obj \
+   $(INTDIR)\dup-safer.obj \
$(INTDIR)\exitfail.obj \
+   $(INTDIR)\fd-safer.obj \
$(INTDIR)\fncase.obj \
$(INTDIR)\fnmatch.obj \
$(INTDIR)\fseeko.obj \
@@ -328,11 +336,21 @@ SOURCE=.\dirname.c
 $(INTDIR)\dirname.obj : $(SOURCE) $(INTDIR)
 
 
+SOURCE=.\dup-safer.c
+
+$(INTDIR)\dup-safer.obj : $(SOURCE) $(INTDIR)
+
+
 SOURCE=.\exitfail.c
 
 $(INTDIR)\exitfail.obj : $(SOURCE) $(INTDIR)
 
 
+SOURCE=.\fd-safer.c
+
+$(INTDIR)\fd-safer.obj : $(SOURCE

Re: Build CVS (TRUNK) failed.

2005-05-06 Thread Mark D. Baushke
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

2005-05-06 Thread Mark D. Baushke
-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.

2005-05-05 Thread Mark D. Baushke
-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

2005-05-04 Thread Mark D. Baushke
-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

2005-05-02 Thread Mark D. Baushke
-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

2005-05-01 Thread Mark D. Baushke
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

2005-04-27 Thread Mark D. Baushke
-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

2005-04-27 Thread Mark D. Baushke
-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

2005-04-27 Thread Mark D. Baushke
-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

2005-04-27 Thread Mark D. Baushke
-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.

2005-04-27 Thread Mark D. Baushke
-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.

2005-04-27 Thread Mark D. Baushke
-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

2005-04-26 Thread Mark D. Baushke
-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

2005-04-26 Thread Mark D. Baushke
-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

2005-04-25 Thread Mark D. Baushke
-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

2005-04-21 Thread Mark D. Baushke
-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

2005-04-15 Thread Mark D. Baushke
-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

2005-04-15 Thread Mark D. Baushke
-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

2005-04-15 Thread Mark D. Baushke
-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

2005-03-22 Thread Mark D. Baushke
-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

2005-03-14 Thread Mark D. Baushke
-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

2005-03-11 Thread Mark D. Baushke
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

2005-03-09 Thread Mark D. Baushke
-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

2005-03-09 Thread Mark D. Baushke
-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

2005-03-07 Thread Mark D. Baushke
-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

2005-03-03 Thread Mark D. Baushke
-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

2005-03-03 Thread Mark D. Baushke
-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

2005-03-03 Thread Mark D. Baushke
-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

2005-03-03 Thread Mark D. Baushke
-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

2005-03-03 Thread Mark D. Baushke
-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

2005-03-02 Thread Mark D. Baushke
-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

2005-03-02 Thread Mark D. Baushke
-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

2005-02-28 Thread Mark D. Baushke
-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

2005-02-27 Thread Mark D. Baushke
-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

2005-02-26 Thread Mark D. Baushke
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]

2005-02-20 Thread Mark D. Baushke
-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

2002-10-24 Thread Mark D. Baushke
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

2002-10-24 Thread Mark D. Baushke
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

2002-10-12 Thread Mark D. Baushke
 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

2002-09-25 Thread Mark D. Baushke

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

2002-09-24 Thread Mark D. Baushke

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

2001-11-27 Thread Mark D. Baushke

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