WinCvs users - query
Hi All, I want to get your opinions regarding the "Commit settings" dialog. This dialog is using the RichEdit control for entering the log message. The problem with RichEdit is that it is quite buggy(selections and such), and it doesn't supply the Right-click menu for CutCopyPaste. I want to replace it with the standard edit box (multiline). The only difference that it makes would be that: 1. Bugs gone. 2. R-click menu back. 3. No formatting visible - the whole thing in B/W, Ms Sans Serif(default font for dialogs). Formatting is not stored anyway, so there is nothing to feel sorry about. Any opinions? Thanks for your time, BR, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: CVSROOT/passwd enhancements
"Larry" == Larry Jones [EMAIL PROTECTED] writes: I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions: First, I'd like to interpret "*" in the password field as "the system password for this user". That would allow people who are not concerned with network security to use system passwords along with user mapping. For example, one could have a CVSROOT/passwd that looked like: john:*:cvsadmin lisa:*:cvsadmin bill:*:cvsuser anne:*:cvsuser Been there done that. This works nice. The current CVS doesn't permit mapping when you want to use a system password. instead of having to give everyone separate CVS passwords or copy their system passwords into CVSROOT/passwd and then having to worry about keeping them in sync. Second, I'd like to interpret "*" in the username field as "any system user". That would allow even more simplification -- for example: *:*:cvsuser I'm a little hesitant on this one. Often repository owners want to limit access. could be used to allow any system user to run CVS; or *:asdfghjklqwer:nobody could be used to allow anyone who knows the password to run CVS. An interesting side-effect of these changes is that the SystemAuth config option would no longer be needed: *:* is equivalent to SystemAuth=yes, and *:x (or any other impossible password) is equivalent to SystemAuth=no. This has the added advantage of keeping all the password-related stuff in one place. Hummm. This is an interesting side effect. I need to think a bit more on this one. My $0.02, Mike Sutton | public class SAIC | software_failure : management_failure Beavercreek, OH | [EMAIL PROTECTED] | These are MY opinions, not SAIC's
RE: CVSROOT/passwd enhancements
Title: RE: CVSROOT/passwd enhancements Aside from any technical issues, doesn't a * in the password field of the password file typically indicate a locked account? I realize that the CVSROOT/passwd is a different file and format but it obviously has roots to /etc/passwd. There might something to be said for maintaining that convention and not confuse the issue. -- Tony Cleveland Development Manager - MicroStation Schematics Bentley Systems, Incorporated voice: (301)926-0802 fax: (301)926-2313 email: [EMAIL PROTECTED] -- -Original Message- From: Chris Cameron [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 23, 2000 6:11 PM To: 'Larry Jones'; [EMAIL PROTECTED] Subject: RE: CVSROOT/passwd enhancements On Wednesday, May 24, 2000 7:40 AM, Larry Jones [SMTP:[EMAIL PROTECTED]] wrote: I'm considering making some enhancements to the CVSROOT/passwd file format and I'd like people's opinions: First, I'd like to interpret * in the password field as the system password for this user. That would allow people who are not concerned with network security to use system passwords along with user mapping. For example, one could have a CVSROOT/passwd that looked like: john:*:cvsadmin lisa:*:cvsadmin bill:*:cvsuser anne:*:cvsuser instead of having to give everyone separate CVS passwords or copy their system passwords into CVSROOT/passwd and then having to worry about keeping them in sync. Second, I'd like to interpret * in the username field as any system user. That would allow even more simplification -- for example: *:*:cvsuser could be used to allow any system user to run CVS; or *:asdfghjklqwer:nobody could be used to allow anyone who knows the password to run CVS. An interesting side-effect of these changes is that the SystemAuth config option would no longer be needed: *:* is equivalent to SystemAuth=yes, and *:x (or any other impossible password) is equivalent to SystemAuth=no. This has the added advantage of keeping all the password-related stuff in one place. We went to the password file because cvs running as any user except root couldn't read the shadow file to verify passwords. This would not change the logic of your changes, but it could reduce the applicability. *** Chris Cameron Open Telecommunications NZ Ltd Software Development Team Leader [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680 New Zealand Life, don't talk to me about life (Marvin - HHGTTG)
TIP on removing directories from working directory
I've often wanted to check out a module, then prune off the directories and files that I didn't need. Until the other day I couldn't figure out a way to do it entirely with CVS commands. What I had been doing is deleting the directory that I didn't want, then manually updating the CVS/Entries file of the parent. This just seemed wrong. The other day I realized that I could use the same mechanism used in the suggested 'cvs ls' equivalent (cvs rdiff -s -r 0 module). I could cause CVS to discard the files I didn't want by specifying a non-existant revision, and prune empty directories. cvs update -r 0 -P file-or-directory-to-remove Hopefully someone else will find this useful. Shane
Re: WinCvs users - query
On Wed, 24 May 2000, Win32 M$ wrote: The change is a good idea, but: OK, what if: 1. Quick solution: I put one more button on this dialog, and then if clicked it would open another dialog with the fonts set to let's say "Courier New 10" and the edit box to enter the message only. After OK on the second dialog the message would be put back in the commit dialog. Why not give the use the option of choosing the font to use there. Or, simpler, force it to be "Courier New 10"? Another button would be too much complication for little gain, really. -- Dimi.
Re: WinCvs users - query
On Wed, 24 May 2000, Win32 M$ wrote: with the standard edit box (multiline). The only difference that it makes would be that: If you do change it PLEASE make it use Courier New 10pt (of whatever is selected for use in the log window, and make it bigger, so that I one could fit 80 columns of text in the window, and have it wordwrap the display. Mark
Re: some question about gCVS.
I would love to run/try gCVS only my box has TCL 8.0 not 8.1, is there anything that makes it 8.1 specific? Not at all. Did you try ? I think gCvs is trying to use 8.0 (see TclGlue.cpp). But if you have only 8.0, you may have also a problem with GTK. GTK needs to be 1.2. Regards, alex. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: WinCvs users - query
Formatting is not stored anyway, so there is nothing to feel sorry about. Being able to write ChangeLog in HTML woul be useful.
Re: CVS Source Repository
Derek R. Price writes: I noticed Larry talking about making changes to CVS and I was wondering if somebody has been maintaining a source repository for CVS since SourceGear bought Cyclic? Or are patches still just floating around? I was under the impression that SourceGear had at least disabled the anonymous access and that no one had really been maintaining patches and such for awhile. Your impression is mistaken -- the official CVS source repository (see the "Developer Information" page at www.cyclic.com) is still up and running for both anonymous and non-anonymous (i.e., developer) access. It survived the transition from Cyclic to SourceGear quite nicely, and lots of changes have been checked in since the last (1.10.8) release. I ask because I am in the process of working with OpenAvenue to get the repository up and running again and thought it would be helpful if somebody had maintained important changes or even a list of patches over the last year or so. I'll do my best to reconstruct said list with the email archives otherwise, but your help is appreciated. Since the current repository is still active, you need to handle this very carefully to ensure that changes don't get lost in the process. Best would be to get the actual machine containing the repository from SourceGear (which is what they did when they bought Cyclic). Failing that, you need to coordinate with them to get a complete copy of the repository (so you keep all the revision history) and ensure that they disable access (at least check-in) during the transition period (which you should try to keep as short as possible). Oh, and before I forget: Wecome aboard! -Larry Jones My "C-" firmly establishes me on the cutting edge of the avant-garde. -- Calvin
Re: Off topic, sort of: best ChangeLog practices?
[ On , May 23, 2000 at 22:25:06 (-0700), Russ Allbery wrote: ] Subject: Re: Off topic, sort of: best ChangeLog practices? One of the problems with abandoning ChangeLog files in favor of the commit messages in a revision control system is that ChangeLogs have this really valuable grouping property when written well. One change is one ChangeLog entry even when it crosses multiple files, and there's often some extra meta-information noted there. One of the problems with ChangeLog files is that unless they are *always* generated automatically they have a tendancy to be "different" in unpredictable ways from the "real" logs. You can kind of do this with CVS, but CVS logs are fundamentally per-file. Either you include information about files other than that particular file in the log message so that you can have the entire description of the change or you end up doing somewhat difficult breaking up of the change description between the multiple log files. And there isn't really any one place to go look to see the whole change in one summary. Typically I always commit all the files at once with the same CVS command (something that's quite easy to do and now even more trivial to do with PCL-CVS) and thus I do end up with the identical log entry on each related revision in each file. There's a lot to be said for the more unified format of ChangeLog files. But unfortunately even if you religiously use something like PCL-CVS to automatically update the ChangeLog file, or even "rcs2log" to generate it at release build time, it's still just a "copy" of what I would hope is the authoritative information. There's a *LOT* more to be said of more formal documentation, including detailed release notes written by someone who reads both the log entries and the actual diffs! ;-) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: Off topic, sort of: best ChangeLog practices?
"Greg A. Woods" wrote:
One of the problems with ChangeLog files is that unless they are
*always* generated automatically they have a tendancy to be "different"
in unpredictable ways from the "real" logs.
Right. They aren't authoritative. I don't see that they have to be.
They can describe, very quickly, what sort of thing was done and
when. If you need to find out exactly what was done, there's always
"cvs diff -u -D ... -D ... | less".
Typically I always commit all the files at once with the same CVS
command (something that's quite easy to do and now even more trivial to
do with PCL-CVS) and thus I do end up with the identical log entry on
each related revision in each file.
Right.
Still, if I were to wonder if there was a change done to support the
FOO environment variable, there's something to be said for reading
the ChangeLog as opposed to doing "cvs log" on likely-looking
files.
ISTM that there's several levels of documentation here, for different
uses. The ChangeLog is for humans to read, providing an overview of
changes done to the system. The "cvs log" is for humans to read,
providing a history of what was done to a given file and why. The
source code is for the machine (and, I certainly hope, humans) to
read, and that provides the definitive answer of what was done in
detail.
But unfortunately even if you religiously use something like PCL-CVS to
automatically update the ChangeLog file, or even "rcs2log" to generate
it at release build time, it's still just a "copy" of what I would hope
is the authoritative information.
Not necessarily even a direct copy of the authoritative information, but
still useful.
There's a *LOT* more to be said of more formal documentation, including
detailed release notes written by someone who reads both the log entries
and the actual diffs! ;-)
That's another piece of documentation, which has the distinct advantage
of being useful for the paying customers. It can be done somewhat
post facto, and probably should at least be revised before shipping
to be more than a chronological list of random changes, some of which
the customers really don't need details of. ("The foo subsystem has
been changed to assure faster performance" is probably better than
"Changed event queue in foo to use a heap" and "Consolidated database
queries in foo initialization" and "Moved slow action from inner to
outer loop" for the customers.)
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
Re: CVS Source Repository
Cameron, Steve writes: [smc] As one who's paranoid about backups, I wonder what measures are being taken to back up the CVS repository that contains CVS. Even in the event of catastrophe, I'm sure somebody will have a recent checkout of the CVS source, but it's not so clear that all the history (the *,v files) would be preserved in such a case. Since I do nightly testing on a number of platforms, I always (except in the event of system hangs and such) have a checkout that's no more than a day old. The checkout is on a fileserver, so it goes through our normal corporate backup process which includes on-line, on-site off-line, and off-site backups, so in the event of a catastrophe I'm reasonably confident that we could recover a reasonably current copy of the code without any problem. This would not, unfortunately, include any history. I presume that SourceGear is taking reasonable precautions to backup the CVS server, but I do not know for a fact that they are, nor do I have any way of doing it remotely. It seems to me that it should be possible to write something very similar to CVSup using only the offical CVS client/server protocol, which would allow anyone to backup any CVS repository they had access to -- anyone looking for a project? -Larry Jones Geez, I gotta have a REASON for everything? -- Calvin
Re: TIP on removing directories from working directory
Someone here suggested the same thing. At first I didn't think that it updated the parent's CVS directory, but I was wrong. It creates the file Entries.Static which tells CVS not to update directories that aren't already checked out. However, the method I suggested works for files, not just directories whereas "cvs release -d" only works on directories. Shane Jerry Nairn wrote: Thanks, That's pretty cool. I'm thinking of how it would be an improvement over "cvs release -d"ing the unwanted folders, though. Doesn't that update the CVS/Entries file? Jerry -Original Message- From: Shane Turner [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 24, 2000 5:15 AM To: [EMAIL PROTECTED] Subject: TIP on removing directories from working directory I've often wanted to check out a module, then prune off the directories and files that I didn't need. Until the other day I couldn't figure out a way to do it entirely with CVS commands. What I had been doing is deleting the directory that I didn't want, then manually updating the CVS/Entries file of the parent. This just seemed wrong. The other day I realized that I could use the same mechanism used in the suggested 'cvs ls' equivalent (cvs rdiff -s -r 0 module). I could cause CVS to discard the files I didn't want by specifying a non-existant revision, and prune empty directories. cvs update -r 0 -P file-or-directory-to-remove Hopefully someone else will find this useful. Shane
Activity-based CVS shell
We just closed an evaluation of source management systems, and the good news is that we are sticking with CVS, Rational ClearCase lost the race. One thing we learnt, though, from talking and reading is that a lot of ClearCase customers take the time to define a process around the product, supported by shell-scripts, triggers, and whatnot. We feel that we want to do the same to CVS, so I am currently busy writing a shell around CVS (in Python) that offers an activity-based interface to the repository. The user typically won't say "I want to create a branch", but rather "I want to start working on bugfix xyz" - the shell will take care of branching, deciding when and what to merge, etcetera. I'm also planning a close integration with the bug tracking system we use, Bugzilla (so that a developer can click a button "Start work on this bug", which results in creating a branch etcetera). I'll be selling this internally as an ideal candidate for an open source solution - after a bit of initial hacking, I'd like to drop the stuff on SourceForge under a BSD or GNU license. Now I cannot promise that I'll be able to pull this through, but it would help me if there would be lots of interest to actually use this stuff in the CVS community. Would people consider/like to/love to switch to a more process-based shell around CVS? Or is the general feeling that this sort of stuff ain't necessary? -- Cees de Groot http://www.cdegroot.com [EMAIL PROTECTED] GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Forge your CipherSaber and list it: http://www.xs4all.nl/~cg/ciphersaber/
Tracking other repositories
Hi, We are developing Java software and using a lot of open source components that are all available through anon CVS. I've been thinking about how to track these components; optimally, I'd like to stay in sync with the "public" CVS development, while at the same time allowing local patches to be CVS-managed. At the same time, as CVS trees of open source projects are typically in flux, especially quality-wise, we'd need to be able to select baselines - versions that are stable enough for our purposes. I've tried a couple of approaches, but none are really satisfactory (I can post my ideas here, but I really don't like what I've written up so far about it). Are more people in this situation, and if yes: are there workable solutions? -- Cees de Groot http://www.cdegroot.com [EMAIL PROTECTED] GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Forge your CipherSaber and list it: http://www.xs4all.nl/~cg/ciphersaber/
Re: CVSROOT/passwd enhancements
When I first studied Unix a few years ago, I read that one should use an asterisk to denote an impossible (i.e. unusable) password because asterisks are not in the set of ciphertext characters used by the Unix password encryption scheme. On our Red Hat Linux and Solaris systems, "x" is used in the password file to indicate that the password is located in the shadow file. Also, "NP" is often used to denote an impossible password. --Avi Larry Jones wrote: Tony Cleveland writes: Aside from any technical issues, doesn't a "*" in the password field of the password file typically indicate a locked account? It's what's traditionally used in /etc/passwd when shadow passwords are in use; this usage seems analogous -- "the password is not here, it is stored elsewhere". It *does* have the convenient property of being an impossible password string, so if the "somewhere else" doesn't exist or doesn't contain a password for this particular user, the account is automatically disabled. Most people I know use "x" (which is also an impossible password string) for intentionally disabled accounts.
Re: CVSROOT/passwd enhancements
On Wed, May 24, 2000 at 03:54:11PM -0400, Avi Green wrote: When I first studied Unix a few years ago, I read that one should use an asterisk to denote an impossible (i.e. unusable) password because asterisks are not in the set of ciphertext characters used by the Unix password encryption scheme. Shouldn't make any difference. The output of any given system's crypt() function is a constant-length string. If the password field is a different length, then no cleartext string can possibly encrypt to it. Also, "NP" is often used to denote an impossible password. Which is why this is safe. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / to me, Charlie Brown represented the courage to be sincere in the face of ridicule. he was NOT a loser. thank you, Mr. Schulz. - Robert C. Mayo
Re: CVS Source Repository
It seems to me that it should be possible to write something very similar to CVSup using only the offical CVS client/server protocol, which would allow anyone to backup any CVS repository they had access to -- anyone looking for a project? The protocol of choice for this seems to be anonymous rsync. At least, that is what we are using at http://sourceware.cygnus.com/ for similar purposes (goal: guard against *both* physical and organizational failures - tape backups and the like can only help with the former). Adding it to the CVS protocol might be cool (for a variety of reasons), but should not get in the way of people putting up anonymous rsync (or CVSup) now.
Re: CVS Source Repository
[ On Wednesday, May 24, 2000 at 14:16:10 (-0400), Larry Jones wrote: ] Subject: Re: CVS Source Repository It seems to me that it should be possible to write something very similar to CVSup using only the offical CVS client/server protocol, which would allow anyone to backup any CVS repository they had access to -- anyone looking for a project? though it's clearly possible I doubt it's even remotely practical it doesn't seem very productive either, especially given the existance of rsync and CVSup and similar tools; and given that there are lots of important reasons to use those tools other than just for backups I think it's more productive to get repository admins to just install one of them -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: WinCvs users - query - 1st summary attempt
Hi All, OK, here is as I see it: 1. 60 chars - NO GO (see below) 2. 80 chars - NO GO (see above) 3. Non-proportional fonts, fonts choice, second dialog with Curier etc. - no go. This is bloat. 4. To keep (1) and (2) quasi solved: Caret position box - watch your limits by yourself! 5. To have (3) quasi solved: Put another button to invoke the viewer(it is already setup in WinCvs, see Preferences-WinCvs), you can type proportional there and after you're done - select all, copy, close, paste (it will be easy since we'll have r-click menu back). 6. Make the box wider - should be enought for 80 chars. No problem, there is space on the right for it. 7. Break the line - no go. Break it yourself supllied with (4) 8. 64K problem on Win9x - it is a Log message, should not be 64K in any case! 9. Write ChangeLog in HTML - NO GO (out of the problem's scope, feel free to type the HTML anyway ;) I am trying to compromise the dialog so to not to bloat it and yet to keep it useful and help you guys to format the log message. However, keep in mind that this dialog is not supposed to be a text editor nor wordprocessor, and a log message should not be too long or complicated. I think that to supply dialog with caret info + button to lauch the editor should keep everybody happy. Once you have the r-click cut/copy/paste menu back it should be fairly easy to make your log message looking the way you like. In any case it should be a gain over the Richedit we have now. Any comments welcome! BR, Jerzy The first thing they don't teach you at school: "Never say never". All the issues not related to the list please send to me in private, thanks.
