Re: making zlib inclusion and pserver optional?
Tirsdag den 27. januar 2004 20:17 skrev Patton, Matthew E., CTR, OSD-PAE: Classification: UNCLASSIFIED While lots of platforms have had zlib for quite some time I realize that not all others (windoze in particular) don't. Shouldn't the configure script use the system zlib instead if it exists? With the recent spate of messages regarding pserver, shouldn't the default be to disable this dangerous mode by default? So those wanting the feature have to build it specifically for themselves? Well yes, pserver can be dangerous to your accountability, but you still do have to enable the socket before it runs. I think it's enough to warn people in the documentation. /Claus ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Ways to find out about removed files
What tools (client or server side) are available that allow one to browse for files which have been removed from a CVS repository. I know the information is stored in the attic directories, but I've been told that there are tools that removes the need to log on to the cvs server and run linux commands to list the files inside those directories. Thanks. jason gibbons ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Multi-tier development CVS plan
I'll be modifying our development process here at the office from 3 tier (development-stage-production) to 4 tier (development-stage-release-production) and I'm trying to make sure I have the best CVS plan. Any feedback (good and bad) would be great. I'm not sure if I'm way off base here or if I'm starting to zero in on the best plan of attack. Planned: Development Branch(s) - All development takes place in development branches. Branching from this branch is permitted for larger clients e.g. create a YOYO branch for custom coding for YOYO \DEV --- \YOYO \FOO Stage Branch This branch will be all ready development branches merged for QC and final testing based on dates/release schedules. - \DEV \STAGE --- \YOYO \FOO Release Branch -- The release branch will always be a current checkout of the same code on production systems, again based on dates/release schedules. -- \DEV \STAGE \RELEASE --- \YOYO \FOO ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: (no subject)
Then use RCS, not CVS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jhon William Parra Sent: Wednesday, January 28, 2004 8:55 AM To: [EMAIL PROTECTED] Subject: (no subject) Hi, i have problems: CVS client win nt. CVS server win nt. I am locking a file and show the next message : cvs [admin aborted]: 'admin -l' is a depreciated option. Use 'edit -c' instead. I want to LOCK THE FILES. thank you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help and info on line endings
At 10:58 AM 1/28/2004, Les Spam wrote: We have been having trouble with line endings because we check out files on a Linux server and zip them up for download by users who do not have CVS clients. Win9x users end up with line oriented text files that do not parse because the scanner sees one long line. Why don't you check them out on a Windows client? ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help and info on line endings
Les Spam writes: We have been having trouble with line endings because we check out files on a Linux server and zip them up for download by users who do not have CVS clients. Win9x users end up with line oriented text files that do not parse because the scanner sees one long line. If you're using the Info-ZIP version of zip, you should use the -l flag to convert the line endings. Can anyone explain how/why it is that the DOS line endings are being preserved in these CVS text files? On Unix-like systems, CR is not part of the line ending, it is part of the line itself. So, if you have a Unix file with DOS line endings and commit it, the CRs get preserved just like all the rest of the characters. If you check that file out on DOS, however, you'll see that the lines end with CRCRLF -- the CR that's part of the line followed by the normal DOS line ending, CRLF. That's almost certainly *not* what you want. As others have said, the rule is that you should always do checkout/checkin on the same kind of system that you're going to use the files on. If you can't (or won't) do that, then it's up to you to handle the line endings yourself. -Larry Jones Hey! What's the matter? Can't you take a joke?! It was a JOKE! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help and info on line endings
Frederic Brehm wrote: At 12:49 PM 1/28/2004, Scott Reed wrote: Why don't you check them out on a Windows client? The server which the users (who do not have CVS clients) access the files is running Linux. The files are automatically, periodically checked out and zipped up for download from the server. SNIP As an alternative, you can have your Linux script check the status of each file. If the Sticky Options: does not include -kb, then do the unix2dos on it. On a checkin, run dos2unix on the same files. WARNING: I don't know if the test for -kb is sufficient. If and Only If there are no -kb's, then there is one other easy option with the zip included with most Linux Distro's these days: -l convert LF to CR LF (-ll CR LF to LF) use `xzip -l [other options]` to create the zips for the windows people and `-ll` to receive zips from them. If you have binaries you could build a script that does the `-l zipfile.zip TextFileList` on known text files and then `-u zipfile.zip BinaryFileList` (I think) to add the binaries to the zip file. SNIP -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Handling JPEG and Gif on WinCVS
Hi, The problem is: When Delhi and Webdesigners try to add files to the repositories receive a error message on WINCVS. The description of the problem is ... I have a question about the option in WinCVS Add Selection. The developer have a Web Site project with HTML Pages and JPGS and Gifs. When I imported the project, CVS (WINCVS) show me a list of extensions and askme the action for each file. It worked well. But when He created a new folder with Images and HTML pges, used the AddSelection option. A Screen appears saing that some problems exists, Cancel or Ignore. I Sad to him to push igore, and let CVS Handle the extensions... But CVS (WinCVS ) import the file without -kb option... And the Imagens come corrupted in the next Checkout. To solve this I edited CVSWRAPPERS and set *.jpeg and *.gif to -k 'b'. But WINCVS still show the error message. I push ignore and the images go with no problem anymore. I have now to find a way to WINCVS dont show the error message... someone can tell me how?? The Delphi developers are receiving the Same message and decided to abort the CVSUse. I see it because Delphi take some binary files in the project. I can set the type of the files in CVS WRAPPERS, But The message will still being showed. Thanks for the help and pacience. Diego Andrade ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Handling JPEG and Gif on WinCVS
Sorry, I forged to type the versions... CVS Version 1.12.5 and WinCVS 1.3.13b - Original Message - From: Diego Ribeiro de Andrade To: Info CVS ; [EMAIL PROTECTED] Sent: Wednesday, January 28, 2004 5:48 PM Subject: Handling JPEG and Gif on WinCVS Hi, The problem is: When Delhi and Webdesigners try to add files to the repositories receive a error message on WINCVS. The description of the problem is ... I have a question about the option in WinCVS Add Selection. The developer have a Web Site project with HTML Pages and JPGS and Gifs. When I imported the project, CVS (WINCVS) show me a list of extensions and askme the action for each file. It worked well. But when He created a new folder with Images and HTML pges, used the AddSelection option. A Screen appears saing that some problems exists, Cancel or Ignore. I Sad to him to push igore, and let CVS Handle the extensions... But CVS (WinCVS ) import the file without -kb option... And the Imagens come corrupted in the next Checkout. To solve this I edited CVSWRAPPERS and set *.jpeg and *.gif to -k 'b'. But WINCVS still show the error message. I push ignore and the images go with no problem anymore. I have now to find a way to WINCVS dont show the error message... someone can tell me how?? The Delphi developers are receiving the Same message and decided to abort the CVSUse. I see it because Delphi take some binary files in the project. I can set the type of the files in CVS WRAPPERS, But The message will still being showed. Thanks for the help and pacience. Diego Andrade ___Info-cvs mailing list[EMAIL PROTECTED]http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Bogus Modified in Future Message
Title: Message Have a bunch of files that were added today at 11:24 AM PST and the date on the repository images concurs. Checking out those files generate a "Warning: modified in future" and a check of the log indicates the files were added at 7:24 PM PST. The client and server clocks look fine so what could account for the log being off by 8 hours? The archive files themselves show they were last updated at 11:24 AM PST so there must be something wacky going on with CVS. Any ideas?This is not the first time this has happened and it has happened on various machines. TIA, Rod ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
patch to make pserver and fix compile bug
Classification: UNCLASSIFIED
turns out --disable-password-authenticated-client won't even compile on
v1.11.11. So I went digging and among some other ancillary bugs and logic
errors, configure also had a notion of
--disable-password-authenticated-server which didn't do anything.
I patched client.c to remove the improperly placed #endif and hand-coded a
new 'configure' to do a better job. I made edits to configure.in but I don't
know how to convert that file into the proper 'configure' script so can't
test it.
Other things I noted (but didn't patch) was the declaration of HAVE_CRYPT in
config.h but nowhere in the entire source tree is it actually used. IMO
server.c needs to be annotated or we should just do away with the check. And
per some of the code comments, why do we care if crypt() happens to be a
dummy/nop?
Another side-issue I briefly noted was that 'configure' doesn't appear to
actually test whether or not the user specified --enable-xxx or
--disable-xxx but rather assumes that if it's set, then do the opposite of
the default whatever that might be - which is hardly benign behavior. This
may be more of an endemic problem with autoconf itself, however or I'm
simply confused.
comments welcome.
--- client.c.orig 2004-01-28 06:22:29.0 -0500
+++ client.c2004-01-28 07:11:53.0 -0500
@@ -3599,6 +3599,7 @@
/* NOTREACHED */
return -1;
}
+#endif /* defined (AUTH_CLIENT_SUPPORT) || defined (HAVE_KERBEROS) ||
defined(HAVE_GSSAPI) */
@@ -3659,7 +3660,6 @@
(BUFMEMERRPROC) NULL);
}
}
-#endif /* defined (AUTH_CLIENT_SUPPORT) || defined (HAVE_KERBEROS) ||
defined(HAVE_GSSAPI) */
--- configure.orig 2004-01-28 07:28:58.0 -0500
+++ configure 2004-01-28 09:01:30.0 -0500
@@ -862,9 +862,9 @@
Disabling this may not work. (default)
--enable-client Include code for running as a remote client
(default)
- --enable-password-authenticated-client
- Enable pserver as a remote access method in the
CVS
- client (default)
+ --enable-password-authentication
+ Enable pserver as a remote access method
+ (disabled by default)
--enable-server Include code for running as a server (default)
--enable-server-flow-control
If you are working with a large remote repository
@@ -11070,12 +11070,6 @@
fi
-
-
-
-
-
-
# Check for options requesting client and server feature. If none are
# given and we have connect(), we want the full client server
arrangement.
# Check whether --enable-client or --disable-client was given.
@@ -11095,26 +11089,6 @@
fi
-# Check whether --enable-password-authenticated-client or
--disable-password-au
thenticated-client was given.
-if test ${enable_password_authenticated_client+set} = set; then
- enableval=$enable_password_authenticated_client
-
-fi;
-
-if test no != $enable_password_authenticated_client; then
- if test no != $enable_client; then
-
-cat confdefs.h \_ACEOF
-#define AUTH_CLIENT_SUPPORT 1
-_ACEOF
-
- else
-{ echo $as_me:$LINENO: WARNING: --enable-password-authenticated-server
is
meaningless with
- the CVS client disabled (--disable-client) 5
-echo $as_me: WARNING: --enable-password-authenticated-server is
meaningless wi
th
- the CVS client disabled (--disable-client) 2;}
- fi
-fi
# Check whether --enable-server or --disable-server was given.
@@ -11262,11 +11236,6 @@
#define HAVE_CRYPT 1
_ACEOF
-
-cat confdefs.h \_ACEOF
-#define AUTH_SERVER_SUPPORT 1
-_ACEOF
-
fi
# Check whether --enable-server-flow-control or
--disable-server-flow
-control was given.
@@ -11330,6 +11299,28 @@
+# Check whether --enable-password-authentication was given.
+if test ${enable_password_authentication+set} = set; then
+ enableval=$enable_password_authentication
+else
+ enable_password_authentication=no
+fi;
+
+if test no != $enable_password_authentication; then
+ if test no != $enable_client; then
+cat confdefs.h \_ACEOF
+#define AUTH_CLIENT_SUPPORT 1
+_ACEOF
+ fi
+ if no != $enable_server; then
+cat confdefs.h \_ACEOF
+#define AUTH_SERVER_SUPPORT 1
+_ACEOF
+ fi
+fi
+
+
+
# Check whether --enable-case-sensitivity or --disable-case-sensitivity was
giv
en.
if test ${enable_case_sensitivity+set} = set; then
enableval=$enable_case_sensitivity
@@ -11395,17 +11386,17 @@
enable_encryption=no
fi;
if test $enable_encryption = yes; then
- if test no != $with_client || test no != $with_server; then
+ if test no != $enable_client || test no != $enable_server; then
cat confdefs.h \_ACEOF
#define ENCRYPTION 1
_ACEOF
else
-{ echo $as_me:$LINENO: WARNING: --enable-encryption is meaningless
with ne
ither the CVS client
- nor the CVS server is enabled (--disable-client and
--disable-server).
5
-echo $as_me: WARNING:
Re: Bogus Modified in Future Message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rod Macpherson [EMAIL PROTECTED] writes: Have a bunch of files that were added today at 11:24 AM PST and the date on the repository images concurs. Checking out those files generate a Warning: modified in future and a check of the log indicates the files Which command is generating this warning? (Is it make?) When soliciting help, it is often useful to provide information like the exact versions of cvs you are using and the exact output with the errors and warnings you are seeing, it is hard to help you remotely diagnose problems when you paraphrase warning messages or do not tell us when you see them. were added at 7:24 PM PST. The client and server clocks look fine so what could account for the log being off by 8 hours? Eight hours is the difference between UTC and PST. The repository should always be keeping its modified timestamps in UTC rather than PST. I would expect to see a file checked in at 11:24AM PST time to show a repository time of 19:24 UTC (aka 7:24PM PST). So, everything looks fine - From that point of view. The archive files themselves show they were last updated at 11:24 AM PST so there must be something wacky going on with CVS. Any ideas? My best guess is that you want to look for an NFS filesystem in the system somewhere that has a different clock for the time on the server of that filesystem. When you do a 'cvs update' the server sets the time on the file to the current time of the checkout and if it is an NFS filesystem, that means the time presently on the NFS server rather than the NFS client. This is not the first time this has happened and it has happened on various machines. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAGCta3x41pRYZE/gRAtNIAKDMVF2YmjymLflz424sUyWzXnC5NQCeIoqg xadtc0fgAyBomUbk7WaiEew= =+UYL -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS on Samba
George, Putting the repository itself on a networked drive (Samba or NFS or others) is generally not recommended. Aparently there is a possiblity with data loss. If you're running a server anyway, I'd just run CVS from the same server and do the checkouts and such via the client-server style of using CVS via SSH or RSH (or pserver, but you didn't hear ME sugest that ;) ). We have a development server here that hosts both home directories mapped via Samba (for those silly people here still using Windows), and runs the CVS server. Most people here actually keep their workspaces on the Samba'd home mount and use a local client to do checkouts from the CVS server. So, the files in the workspace end up on the same machine as the CVS repository, but we always use client-server to make it happen. Even when I work directly logged into the server via ssh, I use pserver to do my checkouts; This lets me use CVS the exact same way both locally and from my workstation via Samba. This seems to work well for us. - Steve George Abraham wrote: Has anyone tried creating a repository on a Samba mounted drive?. Please share your experiences, and points to be kept in mind while doing the same. Regards, George Abraham ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS on Samba
Dear Steve, Thanks for the details you gave on running CVS over samba. I had originally setup the CVS server on a GNU/Linux machine and tried accessing the repository over SSH using WinCVS. My main problem was the client configuration, which was bothersome, in which I had to export the SSH generated public key to the GNU/Linux server. If the developer wanted to checkout a file and work on it in another machine, the same procedure had to be repeated. I wanted to find a way out of that. ( If you have any suggestions, I'd be more than happy). The developers here are used to VSS, and they end up comparing CVS with VSS, without bothering to understand the CVS concept. They want the easiness of VSS, where a developer can use VSS in any machine. I've been trying to achieve that, and I was wondering whether some headway could be made using a Samba served repository. I tried that, and landed up in a lot of permission problems and locks. Any help would be appreciated. I am ready to try out anything. Regards, George Abraham Steve deRosier [EMAIL PROTECTED] 01/29/04 04:03 AM To:George Abraham [EMAIL PROTECTED] cc:[EMAIL PROTECTED] Subject:Re: CVS on Samba George, Putting the repository itself on a networked drive (Samba or NFS or others) is generally not recommended. Aparently there is a possiblity with data loss. If you're running a server anyway, I'd just run CVS from the same server and do the checkouts and such via the client-server style of using CVS via SSH or RSH (or pserver, but you didn't hear ME sugest that ;) ). We have a development server here that hosts both home directories mapped via Samba (for those silly people here still using Windows), and runs the CVS server. Most people here actually keep their workspaces on the Samba'd home mount and use a local client to do checkouts from the CVS server. So, the files in the workspace end up on the same machine as the CVS repository, but we always use client-server to make it happen. Even when I work directly logged into the server via ssh, I use pserver to do my checkouts; This lets me use CVS the exact same way both locally and from my workstation via Samba. This seems to work well for us. - Steve George Abraham wrote: Has anyone tried creating a repository on a Samba mounted drive?. Please share your experiences, and points to be kept in mind while doing the same. Regards, George Abraham ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
