Re: Feature request/ideas
Here is a more detailed description of the tag-extensions:
Terminologie:
Following the mainline (backwards):
Starting from a specific rev. number X on the trunk or a branch, the line is
followed backwards up to the first revision Z on the trunk. It doesn't matter
if there are dead or missing revisions in between. If this first revision is
dead, and its the 1.1 rev., stop here.
If 1.1 is not dead, and 1.1 was created at the same time the first vendor
branch rev. was created, jump to the vendor branch, and take the latest
revision prior to the date of Y (Z is the predecessor of Y).
Otherwise take 1.1.
Absolute tag means a tag that specifies either a revision or a trunk/branch.
'.trunk', 'n.u.m.e.r.i.c' and symbolic tags are absolute tags.
Relative tag means a tag that specifies a revision relative to a certain
starting point.
'.prev', '.next', '.root', '.origin' '.head' and '.base' are relative tags.
The 'focused branch' is used as a synonym for either the trunk or the branch,
depending on the sticky tag of the addressed file or the workdir.
If a relative tag is in head position, the absolute position is calculated from:
1. The sandbox revision's tag
2. The sandbox revision's dir-tag
3. The sandbox revisions revision number
4. The mainline
in this order, whatever is first available.
Absolute tags and relative tags may be combined. If a relative tag follows an
absolute tag, the result will be absolute.
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.
'.trunk': Serves as a synonym for the trunk-branch. Resolves to the most recent
revision of the mainline, and allows to be used as a branch tag if combined
with a date ('xxx -r ".trunk:2005-03-08 18:00:00").
'.origin': Will always resolve to the very first revision.
If a file has been added on a branch, .origin will resolve to the first
revision on
that branch, otherwise it will follow the mainline.
'.root': Will resolv to the predecessor of the first revision on the focused
branch.
'.base': The current sandbox revision. May only be used in head position.
'.head': The most recent revision on the focused branch.
'.prev': The previous revision on the focused branch. Follows the mainline.
'.next': The next revision on the focused branch. Does _not_ follow the
mainline as this would prevent access to revisions on a vendor branch
that were introduced _after_ the first commit/merge onto the trunk.
If a combined tag with relative extensions is used for commands that change
the local sandbox and set sticky tags, the resulting numeric revision is used
for sticky tagging. This is because tags like .trunk.prev.prev imho don't really
make sense -
'.prev', '.next' will force usage of numeric sticky tags in any position, and
all
elative tags will if used not in head position. If the combined tag ends with
'.head', this will overwrite -
I hope I have addressed all issues concerning the new tags,
and would very much appreciate some feedback and maybe
some results from testing ...:-)
>> the patch >>>
Index: src/admin.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/admin.c,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -b -B -u -r1.1.1.3 -r1.2
--- src/admin.c 8 Mar 2005 01:18:17 - 1.1.1.3
+++ src/admin.c 8 Mar 2005 19:37:41 - 1.2
@@ -655,6 +655,10 @@
char *branch = &admin_data->branch[2];
if (*branch != '\0' && ! isdigit ((unsigned char) *branch))
{
+ if (*branch == '.' && !strcmp (branch+1, TAG_TRUNK))
+ branch = NULL;
+ else
+ {
branch = RCS_whatbranch (rcs, admin_data->branch + 2);
if (branch == NULL)
{
@@ -663,6 +667,7 @@
status = 1;
}
}
+ }
if (status == 0)
RCS_setbranch (rcs, branch);
if (branch != NULL && branch != &admin_data->branch[2])
Index: src/commit.c
===
RCS file: /home/frank/CVS_ROOT/ccvs/src/commit.c,v
retrieving revision 1.1.1.2
retrieving revision 1.4
diff -b -B -u -r1.1.1.2 -r1.4
--- src/commit.c2 Mar 2005 01:36:28 - 1.1.1.2
+++ src/commit.c2 Mar 2005 01:40:09 - 1.4
@@ -698,6 +698,10 @@
Lock_Cleanup ();
dellist (&mulist);
+char *commitid = Xasprintf ("@%s", global_session_id);
+tag_check_valid (commitid, argc, argv, local, aflag, "", true);
+free (commitid);
+
/* see if we need to sleep before returning to avoid time-stamp races */
if (
#ifdef SERVER_SUPPORT
@@ -884,8 +888,10 @@
finfo->fullname);
goto out;
}
- if (status == T_MODIFIED && vers->tag &&
- !RCS_isbranch (finfo->rcs, vers->tag))
+ i
Re: [bug-gnulib] GNULIB wait-process module.
Derek Price wrote: > Actually moving the code would be complicated and not symetrical. I > dislike having a process responsible for disposing of temporary data it > did not create. > > In the CVS client/server architecture, there are two servers. The first > authenticates the client and interprets the data coming across in such a > manner as to construct a duplicate of the client workspace. It then > launches a second server which runs, (mostly) unaware that it is not a > CVS application running in local mode against a local repository. > Meanwhile the first server acts in the background, translating the > second server's output into something acceptable to the client. When > the second server completes its job, it exits, then the first server > cleans up the temp space. > > It is this second server's core dumps that are being caught. It > wouldn't be impossible to make it responsible for cleaning up its own > workspace (which it did not create), but it would be a lot of work. > Right now, there is a simple switch in the first server which detects > when the child dumps core and skips the workspace cleanup with an > informative error message. Thanks for explaining. Your objective is clear now. But how would you want this to work on Woe32? I assume that you would want this debugging feature also on Windows. How do you implement it there? > The change I'm proposing is simple. I've attached a patch. I'm opposed to this change because I don't see how it can be made to work on Windows. In other words, it makes unportable assumptions. Bruno ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: windows-NT/mkconfig.pl & windows-NT/fix-msvc-mak.pl change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, > From: Derek Price [mailto:[EMAIL PROTECTED] > > The two files are listed in the subject line. :) Oops, I need another cup of coffee!! :) > First off, the problem cited in your output is not caused by the patch > I just sent, but I'll deal with it anyhow. Yes, I was aware of that but since it prevented an immediate run of the process I wanted you to know the basis of the delay. I didn't intend to imply you needed to act and please don't at this time (see below). > Secondly, I think I would prefer that you use a more modern Perl > release (I've had good luck with the version shipped by ActiveState - > the installer is quick & easy & it doesn't require any external > libraries). I'm happy to try a modern PERL. Expect feedback in a day or two. > Regards, Ditto, > Derek Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi4FMrNM28ubzTo9EQK4WwCfbFDSKfEgvkjCcRxmuILe0mZbLCUAniwR eOM6y6eCr3YObD7vtpNIUTxL =0DRc -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: windows-NT/mkconfig.pl & windows-NT/fix-msvc-mak.pl change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Conrad T. Pino wrote:
|
| Hi Derek,
|
|> From: Derek Price [mailto:[EMAIL PROTECTED]
|
|> I've attached the diff. Conrad or somebody, would you mind
|> verifying that after applying this patch (on WOE32, only the two
|> named files will be relevant)...
|
|
| Please define the phrase "two named" files by enumerating the
| names.
The two files are listed in the subject line. :)
| OK, I'm picking up the goal is run whatever on both Windows and
| UNIX to make sure the generated results are identical.
|
| File "mkconfig.pl" has changes that prevent is from running with
| PERL implementation supplied with old MKS Tool Kit I have on
| Windows 2000. Error output and MKS PERL version information follow
| at message end.
|
| I can install a modern PERL binary release which will take some
| time but I could report back results in a day or two.
|
| What's you preference (1) fix "mkconfig.pl" to run with MKS PERL I
| have or (2) install a modern PERL binary release?
First off, the problem cited in your output is not caused by the patch
I just sent, but I'll deal with it anyhow.
Secondly, I think I would prefer that you use a more modern Perl
release (I've had good luck with the version shipped by ActiveState -
the installer is quick & easy & it doesn't require any external
libraries). If you really don't want to, you could replace the mv
call with a wrapper function which calls rename, followed by a call to
copy and a call to unlink when the initial rename fails. This is
necessary because the source and build dirs might be on different file
systems and a simple rename will usually fail in this case.
File::Copy::mv already handles this.
| H:\Conrad\Projects\cvs-1.12\windows-NT>perl mkconfig.pl "mv" is not
| exported by the File::Copy module at
| C:\MKSToolKit/etc/perl/lib/Exporter.pm line 95 Exporter::export
| called at C:\MKSToolKit/etc/perl/lib/Exporter.pm line 149
| Exporter::import called at mkconfig.pl line 4 main::BEGIN called at
| C:\MKSToolKit/etc/perl/lib/File/Copy.pm line 0 eval {...} called
| at C:\MKSToolKit/etc/perl/lib/File/Copy.pm line 0 Can't continue
| after import errors at mkconfig.pl line 4 BEGIN failed--compilation
| aborted at mkconfig.pl line 4.
|
| H:\Conrad\Projects\cvs-1.12\windows-NT>perl -v
|
| This is perl, version 5.003 with DEBUGGING MULTIPLICITY built under
| Windows_NT at Sep 24 1997 00:36:07 + suidperl security patch
Regards,
Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCLf8TLD1OTBfyMaQRAh6BAJ96voL4e3cRX+UYLMCq/ZzqXsIbWACgvzIp
6GeML8xDlNsGuLWUiBUmf3E=
=zm+7
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] GNULIB wait-process module.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Any further thoughts on this patch?
| 2005-03-04 Derek R. Price <[EMAIL PROTECTED]>
|
| * lib/wait-process.h (wait_subprocess): Accept a new exitsignal
| argument. * lib/wait-process.c (wait_subprocess): Always set
| *exitsignal to 0 when present and set it to the offending signal
| when the child exits due to one.
|
|
| Regards,
|
| Derek
|
|
| --
|
|
| Index: lib/wait-process.c
| ===
| RCS file: /cvsroot/gnulib/gnulib/lib/wait-process.c,v retrieving
| revision 1.3 diff -u -p -r1.3 wait-process.c --- lib/wait-process.c
| 20 Jan 2004 16:47:31 -1.3 +++ lib/wait-process.c4 Mar 2005
| 16:18:13 - @@ -251,7 +251,7 @@ unregister_slave_subprocess
| (pid_t child If it didn't terminate correctly, exit if
| exit_on_error is true, otherwise return 127. */ int
| -wait_subprocess (pid_t child, const char *progname,
| +wait_subprocess (pid_t child, const char *progname, int
| *exitsignal, bool ignore_sigpipe, bool null_stderr, bool
| slave_process, bool exit_on_error) { @@ -345,6 +345,7 @@
| wait_subprocess (pid_t child, const char WAIT_T status;
|
| *(int *) &status = 0; + if (exitsignal) *exitsignal = 0; for (;;)
| { int result = waitpid (child, &status, 0); @@ -390,6 +391,7 @@
| wait_subprocess (pid_t child, const char if (WTERMSIG (status) ==
| SIGPIPE && ignore_sigpipe) return 0; # endif + if (exitsignal)
| *exitsignal = WTERMSIG (status); if (exit_on_error || !null_stderr)
| error (exit_on_error ? EXIT_FAILURE : 0, 0, _("%s subprocess got
| fatal signal %d"), Index: lib/wait-process.h
| ===
| RCS file: /cvsroot/gnulib/gnulib/lib/wait-process.h,v retrieving
| revision 1.2 diff -u -p -r1.2 wait-process.h --- lib/wait-process.h
| 20 Jan 2004 16:47:31 -1.2 +++ lib/wait-process.h4 Mar 2005
| 16:18:13 - @@ -36,11 +36,14 @@ extern "C" {
|
| /* Wait for a subprocess to finish. Return its exit code. If it
| didn't terminate correctly, exit if exit_on_error is true,
| otherwise - return 127. + return 127 and set exitsignal if the
| child terminated because of a signal. Arguments: - child is the pid
| of the subprocess. - progname is the name of the program executed
| by the subprocess, used for error messages. + - exitsignal is an
| optional pointer to an int to hold the signal number of + any
| signal that caused the child to exit. It will be set to zero if
| this + function exits with an error not caused by the child
| catching a signal. - If ignore_sigpipe is true, consider a
| subprocess termination due to SIGPIPE as equivalent to a success.
| This is suitable for processes whose only purpose is to write to
| standard output. This flag can be safely set @@ -52,6 +55,7 @@
| extern "C" { - If exit_on_error is true, any error will cause the
| main process to exit with an error status. */ extern int
| wait_subprocess (pid_t child, const char *progname, +int
| *exitsignal, bool ignore_sigpipe, bool null_stderr, bool
| slave_process, bool exit_on_error);
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCLgJ3LD1OTBfyMaQRAmFLAJ92TMkcy8zKktKMl1SbdC7f2/DeuACg5mbU
SJQ75ER8kCDgUBSMFKgQUdw=
=1Ocs
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: lib/stdint.h intermediate file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: | The build process on Solaris 8 Intel Edition seems to generate | "lib/stdint.h" as an intermediate build product. | | Is there any objection to adding "stdint.h" to the "lib/.cvsignore" | file? None whatsoever. :) Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLgABLD1OTBfyMaQRAssbAKDaJeG3T3cSLXJavO7PPNsf2XqGOACeMBwl AAqkyN+fg3gE+AP938cTPIw= =mb+C -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
lib/stdint.h intermediate file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The build process on Solaris 8 Intel Edition seems to generate "lib/stdint.h" as an intermediate build product. Is there any objection to adding "stdint.h" to the "lib/.cvsignore" file? -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi39HbNM28ubzTo9EQLydACfb4/CNDo6/fQTCmhQivqpp6frXvMAoN1x +w0Dp9pVwQKCztiVzs204YnU =exQ5 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: windows-NT/mkconfig.pl & windows-NT/fix-msvc-mak.pl change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Derek,
> From: Derek Price [mailto:[EMAIL PROTECTED]
>
> I've attached the diff. Conrad or somebody, would you mind verifying
> that after applying this patch (on WOE32, only the two named files will
> be relevant)...
Please define the phrase "two named" files by enumerating the names.
> ...that you can still run the programs?
Yes I will but I'd appreciate an enumerated definition of "the programs"
or a list of commands to run specifying which platform (Windows 2000 or
Solar 8 Intel) to use.
> ... After this change,
> the content of these files generated in WOE or on UNIX should look the
> same (previously, WOE said generated by 'XXX.pl' where UNIX said
> generated by 'xxx').
OK, I'm picking up the goal is run whatever on both Windows and UNIX to
make sure the generated results are identical.
File "mkconfig.pl" has changes that prevent is from running with PERL
implementation supplied with old MKS Tool Kit I have on Windows 2000.
Error output and MKS PERL version information follow at message end.
I can install a modern PERL binary release which will take some time
but I could report back results in a day or two.
What's you preference (1) fix "mkconfig.pl" to run with MKS PERL I have
or (2) install a modern PERL binary release?
> Thanks,
Ditto,
> Derek
Conrad
H:\Conrad\Projects\cvs-1.12\windows-NT>perl mkconfig.pl
"mv" is not exported by the File::Copy module at
C:\MKSToolKit/etc/perl/lib/Exporter.pm line 95
Exporter::export called at C:\MKSToolKit/etc/perl/lib/Exporter.pm line
149
Exporter::import called at mkconfig.pl line 4
main::BEGIN called at C:\MKSToolKit/etc/perl/lib/File/Copy.pm line 0
eval {...} called at C:\MKSToolKit/etc/perl/lib/File/Copy.pm line 0
Can't continue after import errors at mkconfig.pl line 4
BEGIN failed--compilation aborted at mkconfig.pl line 4.
H:\Conrad\Projects\cvs-1.12\windows-NT>perl -v
This is perl, version 5.003 with DEBUGGING MULTIPLICITY
built under Windows_NT at Sep 24 1997 00:36:07
+ suidperl security patch
Copyright 1987-1996, Larry Wall
Win32 port Copyright 1996 by Mortice Kern Systems Inc.
MKS version 6.1 build 209
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.
H:\Conrad\Projects\cvs-1.12\windows-NT>
-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4
iQA/AwUBQi369rNM28ubzTo9EQIHpQCfTD5zOpubbOFMNX/+A90Z2tHoyDEAoO99
lRkHnCub4JB5AFRzXvsOIpJi
=1EEN
-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 wrote: | 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. I've implemented part of this on a branch off 1.11.x named (entries-cache). It passes localcheck but not remotecheck - there are still some places where client.c and maybe server.c are not accessing Entries via the API, either writing or reading them directly. If someone else would like to pick up the torch and correct the rest of the entries references to use the official API, you are welcome to. Otherwise, I'll try and get back to this in a few days or weeks. One final comment is that I implemented this based on 1.11.x, as noted above. I'm not sure this should be the final destination, but I figured it would be easier to port forward than back. At the very least the current version introduces a dependency on the atexit() function (available from GNULIB), but I am not sure this is desirable on stable. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFCLeO5LD1OTBfyMaQRAsMGAJj/G84/x9VptHu4H8ReaYKRUANbAKDLFrHI S8hSVieGbCKp8BgbP3bRrQ== =zvUc -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: GNULib save-cwd.c on Windows & Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Meyering wrote: | Derek Price <[EMAIL PROTECTED]> wrote: | |> I'm afraid I have to agree with Jim Hyslop. Whatever Microsoft's |> flaws, I still believe that some of our mutual user base is at |> least relatively innocent and should still be catered to. | | | This is not about Microsoft per se, but simply about the lack of | fchdir (or POSIX support in general) in WOE. I'm very, very reluctant to introduce a dependency on Cygwin for a single function... | I suppose it's a long shot, but... is there a way, in WOE/MSVC, to | emulate fchdir's behavior? I.e., given a file descriptor that is | the result of opening a directory, can you obtain an absolute path | name of that directory? Glancing at the sources for cygwin, it looks like they decided to save the file name via their open() function and look up the stored value in their fchdir(), then call chdir() on it. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLdnTLD1OTBfyMaQRAgH3AKCV4TwsCiIK2V1M3Ub4zKzeiKyZDgCg0zOZ N0MOMsKS+B3K5zqbg2uzaTY= =qePb -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: GNULib save-cwd.c on Windows & Visual Studio 6.0
Derek Price <[EMAIL PROTECTED]> wrote: > I'm afraid I have to agree with Jim Hyslop. Whatever Microsoft's > flaws, I still believe that some of our mutual user base is at least > relatively innocent and should still be catered to. This is not about Microsoft per se, but simply about the lack of fchdir (or POSIX support in general) in WOE. I suppose it's a long shot, but... is there a way, in WOE/MSVC, to emulate fchdir's behavior? I.e., given a file descriptor that is the result of opening a directory, can you obtain an absolute path name of that directory? BTW if we end up reverting the changes to save-cwd.c, we'll also have to do something about its use of chdir_long, which won't work on systems lacking fchdir: #if !HAVE_FCHDIR # undef chdir_long # define chdir_long(d) chdir (d) #endif ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: GNULib save-cwd.c on Windows & Visual Studio 6.0
On Tuesday 08 March 2005 16:37, Derek Price wrote: > Jim.Hyslop wrote: > | Jim Meyering wrote: > |> Is it an option to use a more modern/POSIX-compliant development > |> environment on Windows? I know that Cygwin now has fchdir and it > |> looks like MKS has support for it, too. > |> > |> > |> If you opt to continue using Visual Studio 6 in spite of this, it > |> must have some important redeeming features. > | > | The problem with the cygwin build is that it requires Cygwin.dll as > | well. The MSVC build stands alone, not requiring any external DLLs. > | > | > | I don't think it is reasonable to require all Windows users to > | download and install Cygwin just to run CVS. > > I'm afraid I have to agree with Jim Hyslop. Whatever Microsoft's > flaws, I still believe that some of our mutual user base is at least > relatively innocent and should still be catered to. I agree with this. Even though I'm not an ms disciple, I know quite some users that would be affected ... -- - The LinCVS Team - http://www.lincvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows & Visual Studio 6.0
[CVS support for MSVC] By the way, I just had a quick look at Visual Studio .NET 2003, and it does not appear to have POSIX support. At least, there's not fchdir function, which is what triggered this whole discussion ;=) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: GNULib save-cwd.c on Windows & Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim.Hyslop wrote: | Jim Meyering wrote: | |> Is it an option to use a more modern/POSIX-compliant development |> environment on Windows? I know that Cygwin now has fchdir and it |> looks like MKS has support for it, too. | | |> If you opt to continue using Visual Studio 6 in spite of this, it |> must have some important redeeming features. | | | The problem with the cygwin build is that it requires Cygwin.dll as | well. The MSVC build stands alone, not requiring any external DLLs. | | | I don't think it is reasonable to require all Windows users to | download and install Cygwin just to run CVS. I'm afraid I have to agree with Jim Hyslop. Whatever Microsoft's flaws, I still believe that some of our mutual user base is at least relatively innocent and should still be catered to. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCLcarLD1OTBfyMaQRAu5RAJ9NJMTJgEZkPrSjdOGLZBYHaIH6KQCg/RnD un34isGInces/lodh1MM4NQ= =emIY -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
CVS Segmentation fault filling /tmp
Hi: Using CVS 1.11.17 running as a pserver on UNIX AIX 5.1 we had a core dump of the CVS server when accessing with wincvs 1.3. Here is a core dump showing the routine causing the segmentation fault. We have not had a problem with the most recent version of tortoise but wincvs seems to be having several problems. Another problem is that the core files are ending up in /tmp which causes OS problems when full. Is this configurable to put the core somewhere else? Thanks, Alex. Alex Forsyth TELUS National Systems Office: 604-432-2185 Cell: 604-816-2748 [EMAIL PROTECTED]:/tmp/cvs-serv93576> dbx /usr/local/bin/cvs core Type 'help' for help. reading symbolic information ...warning: no source compiled with -g [using memory image in core] Segmentation fault in expand_catname at 0xd01f4e54 ($t1) 0xd01f4e54 (expand_catname+0x1c) 9421f780 stwu r1,-2176(r1) (dbx) where expand_catname(0xf00587b0, 0x1, 0x2df23258) at 0xd01f4e54 catopen(??, ??) at 0xd01f5d24 __assert(??, ??, ??) at 0xd02767b0 stdio_buffer_shutdown(0x20234538) at 0x10029bdc buf_shutdown(0x20234538) at 0x1002a398 server_cleanup(0x0) at 0x10026674 error_exit() at 0x100079d0 error(0x1, 0x0, 0x2aa4, 0x27c8, 0x10019e74, 0xd032, 0x6205400, 0x2ff3aeb8) at 0x10007ddc main_cleanup(0x6) at 0x100013a4 SIG_handle(0x6) at 0x10019eb4 abort() at 0xd01f23b4 __assert(??, ??, ??) at 0xd02769b4 stdio_buffer_shutdown(0x20234538) at 0x10029bdc buf_shutdown(0x20234538) at 0x1002a398 server_cleanup(0x0) at 0x10026674 error_exit() at 0x100079d0 error(0x1, 0x0, 0x2aa4, 0x27c8, 0x10019e74, 0xd032, 0x6205400, 0x2ff3aeb8) at 0x10007ddc main_cleanup(0x6) at 0x100013a4 SIG_handle(0x6) at 0x10019eb4 abort() at 0xd01f23b4 __assert(??, ??, ??) at 0xd02769b4 ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows & Visual Studio 6.0
Jim Meyering wrote: > Is it an option to use a more modern/POSIX-compliant development > environment on Windows? I know that Cygwin now has fchdir > and it looks > like MKS has support for it, too. > If you opt to continue using Visual Studio 6 in > spite of this, it must have some important redeeming features. The problem with the cygwin build is that it requires Cygwin.dll as well. The MSVC build stands alone, not requiring any external DLLs. I don't think it is reasonable to require all Windows users to download and install Cygwin just to run CVS. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: GNULib save-cwd.c on Windows & Visual Studio 6.0
"Conrad T. Pino" <[EMAIL PROTECTED]> wrote: > The CVS project compiles the Windows CVS binary with Microsoft Visual > Studio 6.0 which doesn't have a "fchdir" implementation which is used > in "save-cwd.c" module. The comments say: > >Some systems lack fchdir altogether: e.g., OS/2, pre-2001 Cygwin, >SCO Xenix. Also, SunOS 4 and Irix 5.3 provide the function, yet it >doesn't work for partitions on which auditing is enabled. If >you're still using an obsolete system with these problems, please >send email to the maintainer of this code. > > Function "fchdir" is also used in "chdir-long.c" and "openat.c" modules > which may not be used in Windows build. > > What would you suggest for this issue? Hi Conrad, Is it an option to use a more modern/POSIX-compliant development environment on Windows? I know that Cygwin now has fchdir and it looks like MKS has support for it, too. POSIX has required fchdir for a long time, now, and having fchdir lets programs do things like save and restore the working directory much more efficiently and robustly than the alternative getcwd-based implementation would. For example, if you `return' to a saved working directory using chdir, you have to wonder if maybe you've been tricked into changing to some other directory -- or incur the cost of getting/saving/comparing before and after device and inode numbers. If you opt to continue using Visual Studio 6 in spite of this, it must have some important redeeming features. The Unix systems that lack support for fchdir stopped being reasonable porting targets a couple of years ago. And since Cygwin has had fchdir support for over three years, I thought we'd be safe on the WOE side, too. So about a month ago we removed from the save-cwd module support for systems with missing or flaky fchdir support. Although that module could work around the lack of a working fchdir function, the openat module cannot. And since the chdir-long module also uses openat, its use of fchdir is moot. If you have no alternative, it wouldn't be hard to revert the last change to the save-cwd module, but it'd feel like a step backwards. Jim ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
