Re: user names gets the first the characters chopped off
On Tue, 18 Sep 2001, Ask Bjoern Hansen wrote: > I am using the CVS that comes with the latest FreeBSD (--version > says 1.11) plus the attached patch. > > Some users (3 out of 7) gets (once in a while) the first two > characters of their username shopped out. > > The CVS_USER_NAME variable the patch sets is okay, but the username > used in $Id:'s and such are borken. (See example below). Grrh; the patch at http://www.cvshome.org/dev/patches/user is broken. The attached works better. (Robert Spier <[EMAIL PROTECTED]> fixed it up). I've also put it at http://develooper.com/code/cvs/cvs.user.patch - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com *** cvs.h~ Tue Oct 31 01:37:52 2000 --- cvs.h Fri Sep 14 07:30:25 2001 *** *** 277,282 --- 277,285 #define CVSUMASK_ENV"CVSUMASK" /* Effective umask for repository */ /* #defineCVSUMASK_DFLT Set by options.h */ + /* Client user name for the server end of client/server mode */ + #define CVS_USER_NAME_ENV "CVS_USER_NAME" + /* * If the beginning of the Repository matches the following string, strip it * so that the output to the logfile does not contain a full pathname. *** main.c~ Tue Oct 31 01:37:53 2000 --- main.c Fri Sep 14 07:32:51 2001 *** *** 776,781 --- 776,796 server_active = strcmp (command_name, "server") == 0; #endif + /* Set up this environment variable so that the CVSROOT/*info + scripts on the server can know the client's identity. + This is done by setting the CVS_USER_NAME environment + for the environment of the client to match whatever name + was used by the client to get at CVS (as opposed to the + user ID that CVS happens to be running under). */ + + if (!getenv(CVS_USER_NAME_ENV)) { + char *user = getcaller(); + char *env = xmalloc(strlen(user) + strlen(CVS_USER_NAME_ENV) + + 1 + 1); + (void) sprintf(env, "%s=%s", CVS_USER_NAME_ENV, user); + (void) putenv(env); + } + /* This is only used for writing into the history file. For remote connections, it might be nice to have hostname and/or remote path, on the other hand I'm not sure whether
Re: Bidirectional repository synchronization with CVSup - how?
On Fri, Sep 21, 2001 at 03:40:23PM -0500, Art Eschenlauer wrote: > We need to discover or learn about a method whereby changes checked > into one repository may be pulled into copies of that repository > located at our multiple other locations; in effect, each repository > must "become the master" for changes submitted to it so that those > changes can be replicated to other repositores. As Greg says in another message, this isn't going to work too well. > By the way, > - we are using compression, but it doesn't eliminate our problem > - we have found that the performance is too low to have > or commit to a single master repository If the reason you want replication is simply to offload a saturated server and its Internet connection, here's a kludgy sort of hybrid scheme you might try. I've never done this, but I don't see why it wouldn't work. The idea is to distribute the repo -- and thus the workload -- but without replicating it. Put some of your project's modules in a CVS repo on Server 1, and others on Server 2 (generalize to some appropriate N servers). The servers don't all have to be in one place; all you need is to make sure each user has SSH access to them all (or whatever connection method you like, but SSH is by far the safest). When you create a new sandbox, you have to cobble it together with a series of "cvs -d co" commands to the various repositories (I'd write a script to automate it). But once the sandbox has been set up, normal CVS operations (commit, update, log, diff) will transparently fan out to the various servers without further user intervention (except typing passwords; see below). If there's significant locality of reference as to what people work on, you can optimize things by putting each module on a repository close (network-topology-wise) to its major users. E.g. if people at location 1 do most of the work on module A, while people at location 2 only touch it occasionally, put module A's CVS repository on a machine at location 1. Then, the people who use it most will access it at LAN speeds, and only the occasional users will have to suffer Internet-speed access. If people at location 1 are the *only* ones to change module A, and everyone else just reads it, the other sites can optimize still further: they can keep one checked-out working copy of that module in a central, read-only location, with the users' sandboxes linked to it (via symlinks, Makefile vpath's, or whatever suits you). Or you could use CVSup to propagate changes *uni*directionally from each module's master repo to slave repo's at each remote site (use file permissions to enforce that the slave repo's are read-only, otherwise things will get completely bollixed up!) Either way, a given location only has to pay the price of updating each remote module once, rather than for every user, and each server has to serve correspondingly fewer updates. One downside to this scheme is that every time a CVS operation touches a new repo, the user will have to type their passphrase again. That's annoying enough when there's only one repo! But if you choose SSH as your connection mechanism, people can use ssh-agent (part of the SSH package) to get around the problem. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The world has been attacked. The world must respond ... [but] we must be guided by a commitment to do what works in the long run, not by what makes us feel better in the short run. - Jean Chrétien, Prime Minister of Canada ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The future of CVS & Subversion
On Fri, 21 Sep 2001, S. D. wrote: > > On a side note, Clearcase is an option as well, but I don't think we can > > afford the $500k/year to support that behemoth. > > IMHO, ClearCase shouldn't be an option to begin with. If you really can't > stand to use the free tools, look into Perforce. It's much cheaper and has > *vastly* superior tech support. I'll second that. Perforce is very nice if it fits your environment. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
>--- Forwarded mail from Greg Woods: >[ On Thursday, September 20, 2001 at 22:00:31 (-0700), Paul Sander wrote: ] >> Subject: Re: renaming a directory in the checkout / recursive add and commit for >all subdirs >> >> >--- Forwarded mail from Greg Woods: >> > >> > No, you don't have to check out a new sandbox. All the commit comment >> > logs and previous revision deltas, old releases, etc. are all >> > immediately and completely accessible, even without ANY working directory. >> >> I ran a little experiment, the transcript I've included at the bottom of >> this message. The gist is that Greg's claim technically is true, but >> not if CVS best practices are followed. The hiccup is that in order to >> see the complete version history, you can't prune empty directories in >> your workspace. Best practices include adding the -P option to your .cvsrc >> file for checkout and update, which always prunes. >Paul: YOU DO NOT EVEN NEED ANY WORKING DIRECTORY TO SEE ALL HISTORY >You certainly don't have to avoid any "cvs best practices" either. See the transcript below. Your turn to provide transcripts showing how you manage this without a sandbox. >> This assumes a couple of things: First, that the commit comments are >> "meaningful enough", which is rarely the case. >The procedure is documented clearly in the manual. If people don't read >the manual and learn how to do this, as well as follow any additional >local procedures properly, etc., then they probably shouldn't be working >on the project in the first place as they are probably incompetent. If >you only have incompetents to work with then it's not too hard to >concoct a wrapper script to implement a packaged "cvsrename" feature >that does everything for them (though of course if you're paranoid >you'll never trust them to use it so you might just as well do >everything yourself!). Furthermore if it's a multi-person project then >you will have peer review and peer pressure, and if that doesn't work >then nothing will and your project is probably doomed anyway. Only about 10% of the developers I know have ever opened the manual to their version control tool. They rely instead on quick reference cards and get by with the minimum effort. And peer reviews don't usually include commit comments at the moment they're written. They're either done before the commit if the policy is to commit only good code, or they're done after the commit when it's too late to edit the comments. >> Second, to perform a >> merge across directories like this, it's necessary to either do the >> work by hand or create and apply context diffs, and we assume that >> developers are willing and able to do this. In my experience, >> developers prefer not to do the merge by hand, and they don't know >> about the patch(1) program which makes applying context diffs harder. >You must live in some weird space warp Paul. Most programmers I know, >and myself included, have been doing all of that without complaint for >decades now. If it takes a swat with a clue-by-4 to get someone to do >manual merges where necessary then you might want to think twice about >having them on your team in the first place. People who don't know >about 'patch' probably don't know about 'diff' either and obviously have >not read the CVS manual (which mentions the 'patch' program and its uses >explicitly in several places), probably shouldn't be allowed to use cvs, >and certainly shouldn't be maintaining code where any merges are >necessary, manual or otherwise I think you're the one living elsewhere. In my world, merges are avoided like the plague, the developers preferring to minimize the number of large merges performed. CVS makes merging easier when sharing a branch, but the old habits when working on isolated branches remain. And every developer I know uses diff regularly. But they're familiar only with the standard Unix tools and plus the ones in their personal toolkits. They really are unaware of patch until I tell them about it. And no, they don't read the CVS manual because either a) they don't use Emacs, or b) they're not interested in learning all of the nuances of CVS (preferring instead to learn the minimum to get by). None of this means they're poor software engineers; it just means that they're more interested in solving their problems, not jumping through hoops with the uninteresting version control system. >> # Now seek out version history dating back from before the rename >> # I want to see "I WANT TO SEE THIS MESSAGE" recorded in a/b/a.c's >> # version history. >> bugs(paul:.cshrc):a% cvs log >hint: try "cvs log a/b/a.c" You will be able to discover the correct >pathname to use courtesy the (re)birth comment you were supposed to have >written in the first revision of the added file, i.e. the file who's >pathname you do know. Tried that. Didn't work without having a/b in the workspace. That meant having to do an "update -d" to get it. It's all in the
cvs client on windows, repository on solaris
Hi, Can you tell me if there is a way to have a cvs client running on a Windows machine that fetches the files from a repository that resides on a Solaris machine. The catch is that the communication between the client and the repository must use ssh, since my company does not allow unencrypted communication between our servers and clients. /Ola ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
keyword for branch-name?
Is there a keyword for the branch-name of the currently checked out file? I want to use it in a version file, in which I have to print the branch name. Thanks Ulrich DDG Gesellschaft für Verkehrsdaten mbH Niederkasseler Lohweg 20 40547 Düsseldorf Telefon: (0211) 52 777 - 411 Fax : (0211) 52 777 - 409 [EMAIL PROTECTED] > http://www.ddg.de - This Mail has been checked for Viruses Attention: Encrypted mails can NOT be checked! ** Diese Mail wurde auf Viren geprueft Hinweis: Verschluesselte mails koennen NICHT auf Viren geprueft werden! - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
looking for helpful tools for CVS
Do you know helpful programs for CVS (for Linux, AIX or Win) especially I am looking for - GUI client (WinCVS for Linux, AIX) - reporting and analysis progs - automated scripts for standard operations - a progr. that writes all infos about the repository in a database - so you can build SQLs to filter the informations (who commited what and when, infos about automatic merges, infos needed for error-tracking etc) - other progs, that you find cool :-) Thanks very much! Wolfgang Kormann ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Any graphical tool to display merges?
aenginee wrote: > > Hi, > > I am using WinCVS (V1.0.6) and I find that it does not graphically > display merges. Is there any graphical tool (windows or Unix) that runs > against a CVS server and actually display the merges that have taken > place (via arraows going from one the source of the merge to the target > of the merge) WinCVS can use another diff tool (graphical or otherwise) in place of the built-in version. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
The future of CVS & Subversion
I can't seem to find any relevant information on this question (and I hope I don't start a total flame-fest). Is subversion (http://subversion.tigris.org/) the future of CVS, or is it being developed by a totally separate group of individuals? And has subversion been looked at close enough to be determined that it would be a desirable direction to go for current CVS users? Thanks. --Rich ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs client on windows, repository on solaris
Ola Mattsson wrote: > > Hi, > Can you tell me if there is a way to have a cvs client running on a > Windows machine that fetches the files from a repository that resides > on a Solaris machine. > The catch is that the communication between the client and the > repository must use ssh, since my company does not allow unencrypted > communication between our servers and clients. > /Ola To get you started: http://www.cvshome.org/docs/manual/cvs_2.html#SEC28 -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
adding a directory tree to existing module; checkout of subdirectory
hi! suppose you have some module in the repository; (doing a checkout of the whole module and configuring some apache files --> voila it works) now i would like to add an other application (directory tree with code) from another server into the same module of the main server into a certain directory. main module: server1:/home/repository/module1 some server: server2:/home/applicationX desired result: server1:/home/repository/module1/some/.../path/applicationX with ability to maintain the subdir of module1 from server2:/home/applicationX (so checking out a subdirectory from the repository then but without complete path of the repository, only applicationX and not module1/some/.../path/applicationX) thanks alex ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
AW: keyword for branch-name?
Ulrich, the keyword-list in Carl Fogel's book (open source dev. with cvs) shows the $Name$-keyword. As I tested it, it doesn't work (server: cvs 1.11.p1, client WinCVS 1.2). Maybe someone on the list knows more about it. Walter -Ursprüngliche Nachricht- Von: Voigt, Ulrich [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 21. September 2001 11:07 An: '[EMAIL PROTECTED]' Betreff: keyword for branch-name? Is there a keyword for the branch-name of the currently checked out file? I want to use it in a version file, in which I have to print the branch name. Thanks Ulrich DDG Gesellschaft für Verkehrsdaten mbH Niederkasseler Lohweg 20 40547 Düsseldorf Telefon: (0211) 52 777 - 411 Fax : (0211) 52 777 - 409 [EMAIL PROTECTED] > http://www.ddg.de - This Mail has been checked for Viruses Attention: Encrypted mails can NOT be checked! ** Diese Mail wurde auf Viren geprueft Hinweis: Verschluesselte mails koennen NICHT auf Viren geprueft werden! - ___ 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
Monitoring CVS usage
Hi, I have introduced the idea of version-management in an organization that up to date did it manually, diffing source-files every evening and splicing them together again to incorporate changes. When told about software that does that and much more they were quite delighted :-). While making the transition to cvs I would now like to get some sort of overview on who uses it, when and how often. Can that be done? Ciao, MM -- Marian Aldenhövel, Hainstraße 8, 53121 Bonn http://www.marian-aldenhoevel.de "Das wirkliche Leben bleibt eine blaue Blume im Land des Digitalen" W.Höck ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: AW: keyword for branch-name?
Hi there, > Ulrich, > the keyword-list in Carl Fogel's book (open source dev. with cvs) shows the > $Name$-keyword. The $Name$ Keyword is only if you do "cvs export -rTAGNAME" which is replaced by the given TAGNAME. Nothing else. Kind Regards from Aachen. -- Dipl.-Ing. Karl Heinz Marbaise | QIS Systemhaus GmbH Leiter QIS Akademie| Juelicher Strasse 338 email: [EMAIL PROTECTED] | 52070 Aachen Tel. : +49 (241) 4 13 26 - 48 | http://www.qis-systemhaus.de ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The future of CVS & Subversion
Richard F Weber writes: > > Is subversion (http://subversion.tigris.org/) the future of CVS, or is > it being developed by a totally separate group of individuals? It's a completely separate project. -Larry Jones Do you think God lets you plea bargain? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Monitoring CVS usage
Hi Marian, > While making the transition to cvs I would now like to get some sort of > overview on who uses it, when and how often. You can do things like get a e-mail every time some does a checkin, assuming you have your CVS repository on Unix box. Or you can tike a look into history from time to time. An other thing migt be to rename the executable and all users will start script which sends an e-mail to you so you can log all actions and do an statistical analyse of it. Further questions? Kind Regards. -- Dipl.-Ing. Karl Heinz Marbaise | QIS Systemhaus GmbH Leiter QIS Akademie| Juelicher Strasse 338 email: [EMAIL PROTECTED] | 52070 Aachen Tel. : +49 (241) 4 13 26 - 48 | http://www.qis-systemhaus.de ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Monitoring CVS usage
MA> [..skip..] MA> While making the transition to cvs I would now like to get some sort of MA> overview on who uses it, when and how often. Everybody who have to create and modify any *text* files can use it. In company at which I work it is used by programmers, web masters and even managment. When and how often? Personally I never edit any text document or source file without putting it under version control if this document have any importance for me. Ability to have 'time machine' if very helpful. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The future of CVS & Subversion
>--- Forwarded mail from [EMAIL PROTECTED] >I can't seem to find any relevant information on this question (and I >hope I don't start a total flame-fest). >Is subversion (http://subversion.tigris.org/) the future of CVS, or is >it being developed by a totally separate group of individuals? It's a different group of individuals. >And has subversion been looked at close enough to be determined that it >would be a desirable direction to go for current CVS users? Their stated goal is to make Subversion be command-line compatible with CVS, only with fewer problems (e.g. fast application of tags, ability to reorganize the source tree, extensible merge mechanism). Their one big hole right now is a viable tool to convert a CVS repository into a Subversion repository. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Any graphical tool to display merges?
UltraEdit http://www.idmcomp.com/products/features.html ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: adding a directory tree to existing module; checkout of subdirectory
> hi! > suppose you have some module in the repository; > (doing a checkout of the whole module and configuring some apache files --> > voila it works) > now i would like to add an other application (directory tree with code) from > another server > into the same module of the main server into a certain directory. do you mean 'add forever' ? If so, just use cvs import (which allows you to import things as a sub(sub(sub)) directory of an existing module. You can still re-import from the same source, so it's not really 'forever' anyway. > desired result: > server1:/home/repository/module1/some/.../path/applicationX > with ability to maintain the subdir of module1 from > server2:/home/applicationX Look into the documentation of ``the modules'' file (e.g., $CVSROOT/CVSROOT/modules, or the manual or FAQ). You can create aliases and lump things together for checkout. Alternatively, use a script that creates the appropriate symbolic links in the checked-out copies. Philip -- The mail transport agent is not liable for any coffee stains in this message - Philip Lijnzaad, [EMAIL PROTECTED] \ European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: The future of CVS & Subversion
> Richard F Weber writes: > > > > Is subversion (http://subversion.tigris.org/) the future of > CVS, or is > > it being developed by a totally separate group of individuals? > > It's a completely separate project. > The subversion group does include Karl Fogel, the author of the critically acclaimed "Open Source Development with CVS", so there is definite CVS expertise there. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is E-mail notification for checkout possible??
In article <[EMAIL PROTECTED]>, M Hari Hara Prasad wrote: >Hello all, > >While there is an automatic e-mail notification on CVS commits ( through an >entry in $CVSROOT/loginfo), >is there any means of automatic e-mail notification for all the CVS >checkouts made. Such a feature won't scale; what if you have 200 developers; do you want your inbox being spammed? Why do you care about being notified of a completely non-destructive operation? In CVS you can be notified about commits or edits/unedits via the watch feature. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
problem logging in from win32 with pserver
I am having a peculiar problem. I have a cvs server running on a private network, on redhat 7.1, with an ip address of 192.168.0.2. I have a client running windows 98, on a dynamically allocated ip address of 192.168.0.10. Now I have the cvs server set up to allow connection using pserver on port 2401. I use the cvsroot of :pserver:[EMAIL PROTECTED]:/cvsroot >From another linux client this works fine. But when i try and log on using the windows machine (i.e. cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot I get no response and it eventually times out with an error. I have run tcpdump and it appears that when trying to connect from the windows client the server tries to query a nameserver about itself. This is confirmed by the fact that the login works when I dial up and have network access to the nameserver. I have tried 'telnet 192.168.0.2 2401' and this appears to respond correctly with a bad auth error message. Can anyone help? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Monitoring CVS usage
In article <[EMAIL PROTECTED]>, Marian Aldenhoevel wrote: >While making the transition to cvs I would now like to get some sort of >overview on who uses it, when and how often. Lots of freeware projects which have publically accessible CVS repositories. STFW: Search The F... Fine Web! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
[ On Friday, September 21, 2001 at 00:44:42 (-0700), Paul Sander wrote: ] > Subject: Re: renaming a directory in the checkout / recursive add and commit for all >subdirs > > Only about 10% of the developers I know have ever opened the manual to > their version control tool. They rely instead on quick reference cards > and get by with the minimum effort. Then 90% of the developers you know are very poor engineers. No question about it. > And peer reviews don't usually include commit comments at the moment > they're written. Who says they have to be? Peer review is all about learning how to do it better next time so that your peers don't have to fix your mistakes. > I think you're the one living elsewhere. In my world, merges are avoided > like the plague, the developers preferring to minimize the number of > large merges performed. CVS makes merging easier when sharing a branch, > but the old habits when working on isolated branches remain. In my world, where software maintenance makes up 95% of every program's lifetime, merges of one form or another make up well over half of the work done. > And every developer I know uses diff regularly. But they're familiar > only with the standard Unix tools and plus the ones in their personal > toolkits. They really are unaware of patch until I tell them about it. Then you should chastise them for not reading their manuals properly. > And no, they don't read the CVS manual because either a) they don't use > Emacs, Now you're really WAY off in hyperspace Paul. What the hell does emacs have to do with reading the friggin manual!?!?!?!?!? Have you neve heard of the dead tree version? How about the HTML version? Maybe you've forgotten there's a PDF too? And how anyone anywhere could ever confuse the 'info' browser with Emacs stuns me to no end! > or b) they're not interested in learning all of the nuances of > CVS (preferring instead to learn the minimum to get by). This isn't a bloody 'nuance' man! It's a prominently discussed tool in the manual! Why the number of times the word 'patches' alone appears should get anyone with two neurons to rub together to start asking what the heck they are and how to deal with them! > None of this means they're poor software engineers; it just means that > they're more interested in solving their problems, not jumping through > hoops with the uninteresting version control system. I think you'd better go learn what it means to be an engineer. I might not be a "Professional Engineer(tm)", but I've been a practicing engineer (in the traditional definition) almost all of my life. I can assure you that if you don't RTFM then you cannot be an engineer, almost by definition, and certainly never a Professional Engineer(tm). (You could read the code, and be a better engineer, I guess, but I can't expect everyone to do that I guess.) > >hint: try "cvs log a/b/a.c" You will be able to discover the correct > >pathname to use courtesy the (re)birth comment you were supposed to have > >written in the first revision of the added file, i.e. the file who's > >pathname you do know. > > Tried that. Didn't work without having a/b in the workspace. That > meant having to do an "update -d" to get it. It's all in the transcript > of my prior message. OK, so there's a bug. Have you reported it? Do you have a fix? In the mean time "cvs rlog modulepath/a/b/a.c" will work (and without any working directory, obviously). -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The future of CVS & Subversion
[ On Friday, September 21, 2001 at 07:52:17 (-0400), Richard F Weber wrote: ] > Subject: The future of CVS & Subversion > > Is subversion (http://subversion.tigris.org/) the future of CVS, or is > it being developed by a totally separate group of individuals? CVS will have a future so long as any one user continues to use it. Even then CVS will not just disappear. Its source will likely be available for decades after everyone stops using it. If people stop sharing their fixes and updates to it then it may become unusable after 2038 (when the time in seconds since the unix epoch overflows a signed 32-bit int). Then again it might continue to work if time_t is 64-bits. Open source projects don't fight over market share. Smart people use the one which fits their needs, and the rest will use whatever they're told to use. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The future of CVS & Subversion
Greg A. Woods wrote: [EMAIL PROTECTED]"> [ On Friday, September 21, 2001 at 07:52:17 (-0400), Richard F Weber wrote: ] Subject: The future of CVS & SubversionIs subversion (http://subversion.tigris.org/) the future of CVS, or is it being developed by a totally separate group of individuals? CVS will have a future so long as any one user continues to use it.Even then CVS will not just disappear. Its source will likely beavailable for decades after everyone stops using it. If people stopsharing their fixes and updates to it then it may become unusable after2038 (when the time in seconds since the unix epoch overflows a signed32-bit int). Then again it might continue to work if time_t is 64-bits.Open source projects don't fight over market share. Smart people usethe one which fits their needs, and the rest will use whatever they'retold to use. Well, didn't really intend to suggest that CVS would drop off the face of the earth. I was just wondering if it was a natural migration of CVS, or CVS ideals into another project. Just thought I read that Cyclic was bought by CollabNet, and (mis)read that Tigris was part of Collabnet as well. Not that I was expecting CVS to disappear, I've been trying to push CVS to be our company CM system, but see that Subversion is expecting to be stable by end of the year. The decision is then choose the proven and stable CVS, or choose the whizzy-bang (but unproven) Subversion. I was just wondering if any CVS people have looked at it and would consider migrating to Subversion if/when tools become available to assist in migration. Probobally a really prickly subject especially considering SV isn't 100% yet, and hasn't been tested thoroughly yet. On a side note, Clearcase is an option as well, but I don't think we can afford the $500k/year to support that behemoth. --Rich
Unable to connect...
Hi, I've been throught a lot of online documentation, and can't get any answers. I have installed CVS 1.10.8 on a Red Hat 6.2 server and I try to logon with a WinCvs client v.1.2. CVROOT on the server is : :pserver:/my/path CVROOT on the client is : :pserver:[EMAIL PROTECTED]:/my/path When I try to login, a password is asked. I enter it and click "ok" and then, it gives me this error message : NEW CVSROOT: :pserver:[EMAIL PROTECTED]:/my/path (password authentication) cvs login (Logging in to [EMAIL PROTECTED]) Server configuration missing --allow-root in inetd.conf cvs login: authorization failed: server my.server.com rejected access to /my/path for user jkemp *CVS exited normally with code 1* NOTE : Of course "/my/path" and "my.server.com" are only used here as examples. Anyone knows what is wrong ? Thanks a lot Jonathan Kemp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
On Fri Sep 21 2001, 03:44, [EMAIL PROTECTED] (Paul Sander) wrote: > And peer reviews don't usually include commit comments at the moment > they're written. They're either done before the commit if the policy > is to commit only good code, or they're done after the commit when it's > too late to edit the comments. You can always edit commit messages with `cvs admin`. -- Matt http://www.faradic.net/~mmcclure/ "I don't believe in rivalries. I don't believe in curses. Wake up the damn Bambino, maybe I'll drill him in the (behind)." -Pedro Martinez ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: looking for helpful tools for CVS
Wolfgang Kormann wrote: > > Do you know helpful programs for CVS (for Linux, AIX or Win) > > especially I am looking for > - GUI client (WinCVS for Linux, AIX) tkcvs - http://www.twobarleycorns.net/tkcvs.html - Andrew -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The future of CVS & Subversion
Larry Jones wrote: > > Richard F Weber writes: > > > > Is subversion (http://subversion.tigris.org/) the future of CVS, or is > > it being developed by a totally separate group of individuals? > > It's a completely separate project. It's interesting to note though that one of the key developers Karl Fogel wrote one of the most comprehensive books on how to use CVS, and that Subversion is positioning itself to eventually take over many existing users of CVS by fixing many of the issues that have never been resolved in CVS (and arguably can't be because of its design). - Andrew -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Unable to connect...
[EMAIL PROTECTED] writes: > > NEW CVSROOT: :pserver:[EMAIL PROTECTED]:/my/path (password > authentication) > cvs login > (Logging in to [EMAIL PROTECTED]) > Server configuration missing --allow-root in inetd.conf > cvs login: authorization failed: server my.server.com > rejected access to /my/path for user jkemp [...] > Anyone knows what is wrong ? Yes, exactly what the error message says: "Server configuration missing --allow-root in inetd.conf". The CVS line in /etc/inetd.conf should look something like: cvspserver stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/my/path pserver You're missing the --allow-root= part. You're also running a fairly old version. You might want to consider updating to the lastest (1.11.1p1) from www.cvshome.org. -Larry Jones Wow, how existential can you get? -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Excluding directories/files during CVS checkout
I wanted to exclude certain files and directories when a person does a CVS co on a source directory. I dont really need to use 'modules', since I have a really simple setup (the source tree "snips" is under $cvsroot directly). Seems like the only way to do it is using an *alias* module. So I added the following in 'modules': snips -a !snips/exclude1 !snips/exclude2 snips However, doing a cvs co snips choked on this and said module snips has an infinite loop. So I tried renaming the snips directory to snipsdir. But now when the person does a cvs co snips, the files are extracted to 'snipsdir' instead of 'snips'. Anything I am missing? Cant I do directory excludes for a 'regular' module? -vikas ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The future of CVS & Subversion
Well, speaking personally I'm moving all my CVS repositories to Subversion just as soon as it's feasible. YM, of course, MV. -- --- Paul D. Smith <[EMAIL PROTECTED]> HASMAT--HA Software Mthds & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Bidirectional repository synchronization with CVSup - how?
Greetings! We develop software using CVS as an SCM tool. Our developers are located at multiple sites linked by a moderate-speed, moderate-reliability network. CVSup seems like the tool to use to replicate. We need to discover or learn about a method whereby changes checked into one repository may be pulled into copies of that repository located at our multiple other locations; in effect, each repository must "become the master" for changes submitted to it so that those changes can be replicated to other repositores. I have read the CVSup FAQ, especially questions 40-42, which tell me most of what I want to know (including how not to give two revisions produced in two different replicas the same revision number). However, the FAQ does not make it clear whether it is possible and realistic to set up a CVSup replication schedule such as: Location A repeatedly performs { A<-B A<-C A<-D } Location B repeatedly performs { B<-A B<-C B<-D } Location C repeatedly performs { C<-A C<-B C<-D } Location D repeatedly performs { D<-A D<-B D<-C } Is this a reasonable way to proceed? Has anyone observed and documented pitfalls for this approach? By the way, - we are using compression, but it doesn't eliminate our problem - we have found that the performance is too low to have or commit to a single master repository - bitkeeper is not (yet) an option for us Thank you. -Art Art Eschenlauer, Director of Methodology, Sufficient Systems, Inc. [EMAIL PROTECTED]; 612 518-7261 10 2nd St. N.E., Suite 107, Minneapolis, MN 55413 "War is Mankind's most stupid invention." ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: The future of CVS & Subversion
SourceForge is going to offer SV as an alternative to cvs (see http://sourceforge.net/forum/message.php?msg_id=232197). I perceive SV as a nice alternative (just as plain RCS, fancy BitKeeper, artsy PRCS, ambitious aegis, etc. etc.). It might be able to attract a large community, just as CVS has done it. Time will show. But CVS won't go away, and I'd never bet the farm on anything that new. Why not start with CVS (or whatever now), and consider SV a year from now? Kind regards, Peter Ring -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew Johnson Sent: 21. september 2001 21:04 To: [EMAIL PROTECTED] Subject: Re: The future of CVS & Subversion Larry Jones wrote: > > Richard F Weber writes: > > > > Is subversion (http://subversion.tigris.org/) the future of CVS, or is > > it being developed by a totally separate group of individuals? > > It's a completely separate project. It's interesting to note though that one of the key developers Karl Fogel wrote one of the most comprehensive books on how to use CVS, and that Subversion is positioning itself to eventually take over many existing users of CVS by fixing many of the issues that have never been resolved in CVS (and arguably can't be because of its design). - Andrew -- Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ___ 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: The future of CVS & Subversion
IMHO, ClearCase shouldn't be an option to begin with. If you really can't stand to use the free tools, look into Perforce. It's much cheaper and has *vastly* superior tech support. > On a side note, Clearcase is an option as well, but I don't think we can > afford the $500k/year to support that behemoth. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Problems with -f option and checkout
I am trying to use the -f option to check out the head revision if the tag specified by -r is not found. >From the manual: Checkout options -f Only useful with the `-D date' or `-r tag' flags. If no matching revision is found, retrieve the most recent revision (instead of ignoring the file). I tried the following cases: cvs co -f -r TAG1 myfile.c cvs co -f -r TAG2 myfile.c cvs co -f -r TAG3 myfile.c Where: TAG1 is a valid tag for myfile.c TAG2 is a non-existent tag. TAG3 is a valid tag but not for myfile.c. With cvs version 1.10.7 I get the following: Case 1. The code checks out. Case 2. The code doesn't check out. Case 3. The code checks out. Why doesn't Case 2 work? If Case 2 shouldn't work why does Case 3 work? Is this a bug with the cvs -f option or am I missing something? John. -- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
os390
hope this isnt a lame question.. anyone gotten cvs to work on an os390 (no linux isnt installed :) ). I need to have it talk to an AIX box that acts as the repository. Thanks. R. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problems with -f option and checkout
John McNamara writes: > > Why doesn't Case 2 work? If the tag doesn't exist at all, CVS assumes that you've made a mistake and so doesn't do anything. After all, if the tag doesn't exist at all, why are you specifying it with -f instead of just checking out the head? > If Case 2 shouldn't work why does Case 3 work? Actually, Case 3 may or may not work -- it depends on whether the tag is in the CVSROOT/val-tags file or not. If it is, it works; if it's not, it doesn't. -Larry Jones In a minute, you and I are going to settle this out of doors. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: os390
On Fri, Sep 21, 2001 at 11:35:23PM +, r w wrote: > hope this isnt a lame question.. anyone gotten cvs to work on an os390 (no http://mail.gnu.org/pipermail/info-cvs/2001-February/012766.html It still probably needs more testers before the necessary changes could be considered for rolling back into the main tree. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal ("You are in a maze of twisty compiler features, all different"); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The future of CVS & Subversion
[ On Friday, September 21, 2001 at 15:11:23 (-0400), Richard F Weber wrote: ] > Subject: Re: The future of CVS & Subversion > > Well, didn't really intend to suggest that CVS would drop off the face > of the earth. I was just wondering if it was a natural migration of CVS, > or CVS ideals into another project. Just thought I read that Cyclic was > bought by CollabNet, and (mis)read that Tigris was part of Collabnet as > well. There will be a natural migration from CVS to Subversion IFF your specific requirements are better fulfilled by Subversion. > Yuck. Please don't ever send HTML to me or to public mailing lists. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Monitoring CVS usage
[ On Friday, September 21, 2001 at 18:18:53 (GMT), Kaz Kylheku wrote: ] > Subject: Re: Monitoring CVS usage > > Lots of freeware projects which have publically accessible CVS repositories. almost all of the ones on sourceforge.net, as a matter of fact! ;-) -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problems with -f option and checkout
On Fri, Sep 21, 2001 at 08:12:29PM -0400, Larry Jones wrote: > John McNamara writes: > > > > Why doesn't Case 2 work? > > If the tag doesn't exist at all, CVS assumes that you've made a mistake > and so doesn't do anything. After all, if the tag doesn't exist at all, > why are you specifying it with -f instead of just checking out the head? > > > If Case 2 shouldn't work why does Case 3 work? > > Actually, Case 3 may or may not work -- it depends on whether the tag is > in the CVSROOT/val-tags file or not. If it is, it works; if it's not, > it doesn't. [Not disagreeing with Larry; just elaborating] Case 3 is supposed to work all the time. CVSROOT/val-tags exists specifically to let CVS distinguish Cases 2 and 3 (the only other way would be to recursively search the entire repo for files containing the requested tag -- obviously a non-starter). But val-tags is not always correct; tags that are supposed to be listed in it aren't always there. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The world has been attacked. The world must respond ... [but] we must be guided by a commitment to do what works in the long run, not by what makes us feel better in the short run. - Jean Chrétien, Prime Minister of Canada ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Bidirectional repository synchronization with CVSup - how?
[ On Friday, September 21, 2001 at 15:40:23 (-0500), Art Eschenlauer wrote: ] > Subject: Bidirectional repository synchronization with CVSup - how? > > We develop software using CVS as an SCM tool. Our developers are > located at multiple sites linked by a moderate-speed, > moderate-reliability network. CVSup seems like the tool to use to > replicate. Probably not, actually The only way CVSup will work for you is if you can: (a) choose one actual site as the real master site and replicate out from there; (b) do all work at slave sites on branches; and (c) dedicate someone to doing merges from the site branches to some master branch. CVSup cannot work miracles. It is only able to share changes between a master site and one or more slave sites if the changes at slave sites occur on branches which are guaranteed to be absolutely unique to the given site. If you go look at the research into distributed databases you'll find that you're asking to solve a problem that the research community still doesn't consider to be solved to the extent necessary for real-world production uses. > - bitkeeper is not (yet) an option for us That's too bad because BK solves this problem in a very elegant and effective fashion (by avoiding it all together and instead treating all change sets as independent lines of development and allowing anyone and everyone to have a full "master" copy of a shared repo). -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
>--- Forwarded mail from [EMAIL PROTECTED] >[ On Friday, September 21, 2001 at 00:44:42 (-0700), Paul Sander wrote: ] >> Subject: Re: renaming a directory in the checkout / recursive add and commit for >all subdirs >> >hint: try "cvs log a/b/a.c" You will be able to discover the correct >> >pathname to use courtesy the (re)birth comment you were supposed to have >> >written in the first revision of the added file, i.e. the file who's >> >pathname you do know. >> >> Tried that. Didn't work without having a/b in the workspace. That >> meant having to do an "update -d" to get it. It's all in the transcript >> of my prior message. >OK, so there's a bug. Have you reported it? Do you have a fix? I don't see it as a bug, so I have no reason to report it. Feel free to report it if you believe differently. >In the mean time "cvs rlog modulepath/a/b/a.c" will work (and without >any working directory, obviously). Really? Here's the response I get: bugs(paul:.cshrc):paul% cvs rlog a/b cvs log: warning: the rlog command is deprecated cvs log: use the synonymous log command instead cvs [log aborted]: no such directory `a' Do you have any more ideas? >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming a directory in the checkout / recursive add and commit for all subdirs
[ On Friday, September 21, 2001 at 18:45:22 (-0700), Paul Sander wrote: ] > Subject: Re: renaming a directory in the checkout / recursive add and commit for all >subdirs > > >In the mean time "cvs rlog modulepath/a/b/a.c" will work (and without > >any working directory, obviously). > > Really? Here's the response I get: > > bugs(paul:.cshrc):paul% cvs rlog a/b > cvs log: warning: the rlog command is deprecated > cvs log: use the synonymous log command instead > cvs [log aborted]: no such directory `a' > > > Do you have any more ideas? You're running an old and broken version of CVS -- time to upgrade. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs