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