Re: cvs update $Name: $ expansion
[EMAIL PROTECTED] wrote: I can't get $Name: $ to expand on an update in my script below. It works when checking out. But, do I really have to do a checkout? I think it works on update, *if* the working copy is missing and the update has to get a new copy from scratch. (And, of course, if the sandbox has a sticky revision tag.) So if you use $Name$ in a single file, you can get that file to expand correctly without having to check out the entire project. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs update $Name: $ expansion
I can't get $Name: $ to expand on an update in my script below. It works when checking out. But, do I really have to do a checkout? Because a clean checkout every night would be expensive over a crappy connection. debian$ cat test.sh DATE=`date +%s` TAG=test_$DATE MODULE='t' echo Tagging module: $MODULE with tag: $TAG # Snapshot the module in the repo cvs rtag $TAG $MODULE # Updating to that snapshot cvs update -r $TAG tag=$Name: $ echo $tag |sed 's/^.*: //;s/ .*$//' You're very mixed up here. The whole point of $Name: $ is you put them in your source files and they get automagically transformed for you on checkin and checkout. You don't use them as tag names and you shouldn't be doing sed magic by yourself. Common idiom (in say a Perl project) #!/usr/bin/perl # $Id$ use DBI; ...etc etc rest of script goes here After the next checkin/checkout you get some nice info on the state of the file #!/usr/bin/perl # $Id: newDSLTests.pl,v 1.19 2005/04/15 04:00:58 scooper Exp $ use DBI; There's a trick in C programming, something like static char RCSId[]=$Id$; and it gets compiled into the executable so it can later be found as a string in the executable so you know what versions made up your compiled software. Take a few steps back and think about what $Id$, $Name$ are all about. Have fun, Stuart. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs update $Name: $ expansion
I want some sort of build identifier attached to the source I am building every night. $Name:$ seems logical and it does seem like the way other people do it, albeit with a checkout. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs update $Name: $ expansion
I want some sort of build identifier attached to the source I am building every night. Then tag your sources every night in eg astronomical time rev20050623 for July 23rd. $Name:$ seems logical and it does seem like the way other people do it, albeit with a checkout. Yes, it only gets expanded on checkout: from info cvs: `$Name$' Tag name used to check out this file. The keyword is expanded only if one checks out with an explicit tag name. For example, when running the command `cvs co -r first', the keyword expands to `Name: first'. And you don't want users to check out the whole source tree. But if you tag your regular build, users can update their sources with cvs update -r rev20050623 and less stuff will get sent over the network and they'll be running with the 20050623 'nightly build'. They won't be able to check in changes to this since it's a non-branch tag, but they will be able to try out nightly snapshots in this way. cvs update -A will remove the sticky tag and bring them up to HEAD when they need to do that. So you associate the build identifier to your source tree through the tag. Users won't get much clue looking at the source files themselves, CVS/Entries in each directory will show that they've checked out the rev20050623 tag however. Hope this helps, Stuart. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS update -j branch-tag failes to merge
On Wed, May 18, 2005 at 12:53:03PM -0400, Jim Hyslop wrote: Asbjørn Sæbø wrote: On Fri, May 13, 2005 at 03:58:12PM -0400, Jim Hyslop wrote: What version of client and server are you using? Both are 1.12.9 Hmmm... I just tried it with 1.12.12, and it worked OK. Can you upgrade to the latest versions and try again? Now I have tested again, on clean checkouts, with both 1.12.9 and 1.12.12. The results seem to indicate a difference between these two versions. With 1.12.12, the expected merging takes place, with 1.12.9 it does not. Actually, it seems that what makes the difference is whether the client is 1.12.12 or not (see below). When the client is 1.12.12, the merging I am expecting takes place. When the client is 1.12.9, it does not. (It should be mentioned that I am not totally certain that my repository is sound. I installed cvs the normal way (apt-get install on a Debian-based box). But the actual ldas module is just copied to this server from another one. It seems to work, but I am not sure whether this is the formally correct way to transfer a module to another server.) Procedure: -- rm -rf ldas cvs co ldas cvs update -j dev_20050413_b ldas The output from the update -j command is shown below. (The output is truncated for the cases where merging took place.) Case 1: --- client: cvs 1.12.9 server: 1.12.9 [EMAIL PROTECTED]:~/tmp/tmp$ cvs update -j dev_20050413_b ldas cvs update: Updating ldas cvs update: Updating ldas/doc cvs update: Updating ldas/doc/doxygen cvs update: Updating ldas/doc/ldasdoc cvs update: Updating ldas/doc/ldasdoc/developer cvs update: Updating ldas/doc/ldasdoc/reference cvs update: Updating ldas/doc/ldasdoc/spec cvs update: Updating ldas/doc/ldasdoc/usermanual cvs update: Updating ldas/extracode cvs update: Updating ldas/orig_src cvs update: Updating ldas/src cvs update: Updating ldas/testcode [EMAIL PROTECTED]:~/tmp/tmp$ Case 2: --- client: cvs 1.12.12 server: 1.12.12 [EMAIL PROTECTED]:~/tmp/tmp$ cvs update -j dev_20050413_b ldas cvs update: Updating ldas RCS file: /local/cvs/ldas/Tags,v retrieving revision 1.17 retrieving revision 1.17.2.2 Merging differences between 1.17 and 1.17.2.2 into Tags rcsmerge: warning: conflicts during merge cvs update: Updating ldas/doc [...] cvs update: Updating ldas/doc/ldasdoc/reference cvs update: Updating ldas/doc/ldasdoc/spec RCS file: /local/cvs/ldas/doc/ldasdoc/spec/specification.tex,v retrieving revision 1.6 retrieving revision 1.6.4.1 Merging differences between 1.6 and 1.6.4.1 into specification.tex ldas/doc/ldasdoc/spec/specification.tex already contains the differences between 1.6 and 1.6.4.1 [More merging] Case 3: --- Client: 1.12.12 Server: 1.12.9 [EMAIL PROTECTED]:~/tmp/tmp$ cvs update -j dev_20050413_b ldas cvs update: Updating ldas RCS file: /local/cvs/ldas/Tags,v retrieving revision 1.17 retrieving revision 1.17.2.2 Merging differences between 1.17 and 1.17.2.2 into Tags rcsmerge: warning: conflicts during merge cvs update: Updating ldas/doc [...] cvs update: Updating ldas/doc/ldasdoc/spec RCS file: /local/cvs/ldas/doc/ldasdoc/spec/specification.tex,v retrieving revision 1.6 retrieving revision 1.6.4.1 Merging differences between 1.6 and 1.6.4.1 into specification.tex ldas/doc/ldasdoc/spec/specification.tex already contains the differences between 1.6 and 1.6.4.1 [More merging] Case 4: --- Client: 1.12.9 Server: 1.12.12 [EMAIL PROTECTED]:~/tmp/tmp$ cvs update -j dev_20050413_b ldas cvs update: Updating ldas cvs update: Updating ldas/doc cvs update: Updating ldas/doc/doxygen cvs update: Updating ldas/doc/ldasdoc cvs update: Updating ldas/doc/ldasdoc/developer cvs update: Updating ldas/doc/ldasdoc/reference cvs update: Updating ldas/doc/ldasdoc/spec cvs update: Updating ldas/doc/ldasdoc/usermanual cvs update: Updating ldas/extracode cvs update: Updating ldas/orig_src cvs update: Updating ldas/src cvs update: Updating ldas/testcode [EMAIL PROTECTED]:~/tmp/tmp$ Asbjørn ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS update -j branch-tag failes to merge
On Fri, May 13, 2005 at 03:58:12PM -0400, Jim Hyslop wrote: Asbjørn Sæbø wrote: On Fri, May 13, 2005 at 10:04:59AM +0200, Asbjørn Sæbø wrote: [Updating/merging did not work from outside the module/directory, but worked from inside the directory. ] [EMAIL PROTECTED]:~/ldas/utvikling$ cvs update -j dev_20050413_b ldas [Did not merge] [EMAIL PROTECTED]:~/ldas/utvikling/ldas$ cvs update -j dev_20050413_b . [Worked, did merge] [Much retrieving and merging] Is this difference between naming the module/directory and standing in the module/directory expected behaviour? No. I just tried it with cvs 1.11.20, and it worked OK: [...] What version of client and server are you using? Both are 1.12.9 Asbjørn ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS update -j branch-tag failes to merge
Asbjørn Sæbø wrote: On Fri, May 13, 2005 at 03:58:12PM -0400, Jim Hyslop wrote: What version of client and server are you using? Both are 1.12.9 Hmmm... I just tried it with 1.12.12, and it worked OK. Can you upgrade to the latest versions and try again? -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS update -j branch-tag failes to merge
On Fri, May 13, 2005 at 10:04:59AM +0200, Asbjørn Sæbø wrote: I have a CVS module (named ldas) where I would like to merge the contents of a branch into the trunk. According to the documentation, is seems that I should be able to du this using cvs update -j branch-tag. However, this does not work. No merging takes place, the files on the trunk do not receive the changes from the branch. [...] [EMAIL PROTECTED]:~/ldas/utvikling$ cvs update -j dev_20050413_b ldas However, when I changed into the ldas directory, and did the update, it worked: [EMAIL PROTECTED]:~/ldas/utvikling$ cd ldas [EMAIL PROTECTED]:~/ldas/utvikling/ldas$ cvs update -j dev_20050413_b . [Much retrieving and merging] Is this difference between naming the module/directory and standing in the module/directory expected behaviour? Asbjørn -- Asbjørn Sæbø, post.doc. Centre for Quantifiable Quality of Service in Communication Systems Norwegian University of Science and Technology URL: http://www.q2s.ntnu.no/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS update -j branch-tag failes to merge
Asbjørn Sæbø wrote: On Fri, May 13, 2005 at 10:04:59AM +0200, Asbjørn Sæbø wrote: I have a CVS module (named ldas) where I would like to merge the contents of a branch into the trunk. According to the documentation, is seems that I should be able to du this using cvs update -j branch-tag. However, this does not work. No merging takes place, the files on the trunk do not receive the changes from the branch. [...] [EMAIL PROTECTED]:~/ldas/utvikling$ cvs update -j dev_20050413_b ldas However, when I changed into the ldas directory, and did the update, it worked: [EMAIL PROTECTED]:~/ldas/utvikling$ cd ldas [EMAIL PROTECTED]:~/ldas/utvikling/ldas$ cvs update -j dev_20050413_b . [Much retrieving and merging] Is this difference between naming the module/directory and standing in the module/directory expected behaviour? No. I just tried it with cvs 1.11.20, and it worked OK: C:\cvs-test\jimcvs -d \cvs_repository tag -r brach_base -b abranch cvs tag: Tagging . T test.txt C:\cvs-test\jimcvs up -r abranch cvs update: Updating . C:\cvs-test\jimecho branch changestest.txt C:\cvs-test\jimcvs ci -m branch changes test.txt Checking in test.txt; \cvs_repository/cvs-test/jim/test.txt,v -- test.txt new revision: 1.2.2.1; previous revision: 1.2 done C:\cvs-testcvs up -A jim cvs update: Updating jim U jim/test.txt C:\cvs-testcvs up -j abranch jim cvs update: Updating jim RCS file: \cvs_repository/cvs-test/jim/test.txt,v retrieving revision 1.2 retrieving revision 1.2.2.1 Merging differences between 1.2 and 1.2.2.1 into test.txt What version of client and server are you using? -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs update not handling binary files with conflicts correctly
[...] When the update command is run it says that there is a conflict in the WORD.tar (binary file). But when I ran cvs -nq update after the changes are merged it shows that the Binary file has no conflicts. It is supposed to mark it with a 'C' right? CVS already told you... $ cvs -f up -d -kk -j TAG1 -j TAG2 WORD.tar test9.txt cvs update: nonmergeable file needs merge cvs update: revision 1.1.2.2 from repository is now in WORD.tar cvs update: file from working directory is now in .#WORD.tar.1.1.4.2 Which basically means that the WORD.tar revision is now the same as in the repository. If you want to create your conflict again, do a $ mv .#WORD.tar.1.1.4.2 WORD.tar and run cvs up Arno np: Marillion - The Fruit Of The Wild Rose ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs update -A doesn't work . . . ?
Christopher Currie wrote: I'm trying to commit a file that has a sticky tag: cvs server: sticky tag `1.8' for file `shopnav.ascx' is not a branch cvs [server aborted]: correct above errors first! From all the documentaton I have, I read that the way to clear the sticky tag was to do a: cvs update -A but this doesn't do a thing. Are you sure? What does 'cvs stat shopnav.ascx' report, right after 'cvs update -A'? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs update -A doesn't work . . . ?
Robert -- the output of 'status,' 'update,' 'status,' and then a final try at commiting the file is below. By 'doesn't do a thing,' I mean that the status of the file doesn't seem to change nor can I commit the file. I'm new to cvs, and I've been reading the documentation and the cvs book (by Jennifer Vesperman), but I'm still quite lost about what the problem is exactly. Thanks Robert. - Christopher -Original Message- From: Robert Helmer [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 12:59 PM To: Christopher Currie Cc: info-cvs@gnu.org Subject: Re: cvs update -A doesn't work . . . ? On Tue, Apr 05, 2005 at 11:49:00AM -0400, Christopher Currie wrote: I'm trying to commit a file that has a sticky tag: cvs server: sticky tag `1.8' for file `shopnav.ascx' is not a branch cvs [server aborted]: correct above errors first! From all the documentaton I have, I read that the way to clear the sticky tag was to do a: cvs update -A but this doesn't do a thing. What do you mean by doesn't do a thing? No output, does not change the situation, ? You can see current sticky tags on a file with cvs status file, and update just that file to the trunk using cvs update -A file. Are you sure you are in the right directory, and are operating on a CVS module that's been checked out (e.g. not one directory up)? Please send the full output of these commands: cvs status file cvs up -A file cvs status file -- Rob +-- REQUESTED OUTPUT --+ cvs status shopnav.ascx * CVS exited normally with code 0 * === File: shopnav.ascx Status: Locally Modified Working revision:1.8 Repository revision: 1.8 \cvsrepo_web/Development/common/shopnav.ascx,v Sticky Tag: 1.8 Sticky Date: (none) Sticky Options: (none) cvs up -A shopnav.ascx * CVS exited normally with code 0 * M shopnav.ascx cvs status shopnav.ascx * CVS exited normally with code 0 * === File: shopnav.ascx Status: Locally Modified Working revision:1.8 Repository revision: 1.8 \cvsrepo_web/Development/common/shopnav.ascx,v Sticky Tag: 1.8 Sticky Date: (none) Sticky Options: (none) cvs -z9 commit -m shopnav.ascx cvs server: sticky tag `1.8' for file `shopnav.ascx' is not a branch cvs [server aborted]: correct above errors first! ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs update -A doesn't work . . . ?
Christopher Currie wrote: Robert -- the output of 'status,' 'update,' 'status,' and then a final try at commiting the file is below. [...] === File: shopnav.ascxStatus: Locally Modified Working revision: 1.8 Repository revision: 1.8 \cvsrepo_web/Development/common/shopnav.ascx,v Sticky Tag:1.8 Sticky Date: (none) Sticky Options:(none) cvs up -A shopnav.ascx * CVS exited normally with code 0 * M shopnav.ascx cvs status shopnav.ascx * CVS exited normally with code 0 * === File: shopnav.ascxStatus: Locally Modified Working revision: 1.8 Repository revision: 1.8 \cvsrepo_web/Development/common/shopnav.ascx,v Sticky Tag:1.8 Sticky Date: (none) Sticky Options:(none) Something is definitely wrong here. At this point, Sticky Tag should say (none). What is generating the * CVS exited ... messages? Those are not generated by CVS. Which version of CVS are you running (both on the client and on the server)? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs update -A doesn't work . . . ?
Jim, cvs on our server is version 1.3.2.03, and on our client machines, the version is: 1.3.20.3 Beta (Build 3), WINCVS. Thanks Jim. - Christopher P.S. I've been using the command line interface of WINCVS to run cvs commands. -Original Message- From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 1:39 PM To: '[EMAIL PROTECTED]'; Robert Helmer Cc: info-cvs@gnu.org Subject: RE: cvs update -A doesn't work . . . ? Christopher Currie wrote: Robert -- the output of 'status,' 'update,' 'status,' and then a final try at commiting the file is below. [...] === File: shopnav.ascxStatus: Locally Modified Working revision: 1.8 Repository revision: 1.8 \cvsrepo_web/Development/common/shopnav.ascx,v Sticky Tag:1.8 Sticky Date: (none) Sticky Options:(none) cvs up -A shopnav.ascx * CVS exited normally with code 0 * M shopnav.ascx cvs status shopnav.ascx * CVS exited normally with code 0 * === File: shopnav.ascxStatus: Locally Modified Working revision: 1.8 Repository revision: 1.8 \cvsrepo_web/Development/common/shopnav.ascx,v Sticky Tag:1.8 Sticky Date: (none) Sticky Options:(none) Something is definitely wrong here. At this point, Sticky Tag should say (none). What is generating the * CVS exited ... messages? Those are not generated by CVS. Which version of CVS are you running (both on the client and on the server)? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs update -A doesn't work . . . ?
Christopher Currie wrote: cvs on our server is version 1.3.2.03, and on our client machines, the version is: 1.3.20.3 Beta (Build 3), WINCVS. Thanks Jim. - Christopher P.S. I've been using the command line interface of WINCVS to run cvs commands. WinCVS uses CVSNT, not CVS (there is a difference). I'm afraid we're not going to be much help for you. For CVSNT support, you should go to www.cvsnt.com Except that it seems to be down at the moment :=( -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs update: move away file; it is in the way
Rachel Suddeth wrote: Oh nevermind. I see there is an uncontrolled file by the same name in the sandbox. Glad we could help :=) BTW, with respect to this question: I'm not sure how to say if a message came from CVSNT client, or the server running under Linux the first part of the message tells you where it originated: cvs server: Updating BhCtrl/BHTypes cvs server - the server generated the message. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs update: move away file; it is in the way
Hello, * On Thu, Dec 09, 2004 at 08:27:40AM -0600 Rachel Suddeth wrote: I got this in output window from WinCVS. I'm not sure how to say if a message came from CVSNT client, or the server running under Linux but I'm guessing server since path has /, not \ in it... cvs server: Updating BhCtrl/BHTypes cvs update: move away BhCtrl/BHTypes/BHTypes.csproj; it is in the way. You want to checkout (or, in this case, update) the file BhCtrl/BHTypes/BHTypes.csproj from the repository, but this file is already in your sandbox. Unfortunately, the file is not under control of CVS. Thus, CVS does not want to overwrite it, as you might loose the file if it is totally different to what is checked out here. Have you copied the file by hand into the sandbox? You can rename the file BHTypes.csproj to something different and look what CVS checks out for you. Furthermore, I have seen this problem on the CVSHOME version of CVS on Windows systems if there are files in the repository which differ only in the case. Well, IIRC, it was more if there are directories which only differ by case. For more details, see the thread I started here Date: Sun, 18 Apr 2004 18:37:32 +0200 Subject: Windows with Dir/ and dir/ From: Spiro Trikaliotis [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] (sorry, the archive does not work now, so I cannot give you an URL) HTH, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs-update triggers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: i would like to setup a trigger for when cvs-update touches a file (updates or merges) in checked out work areas. is there already a mechanism for this? No. The Set-update-prog feature was removed for cvs 1.11.6. It is a potential security vulnerability to have a cvs update run commands on your behalf that someone else has defined. i want it to run a script or set of commands my specific need is that i want to have a shell-rc file in the repository, when someone makes changes to it and then i do an update, i get those changes and therefore would like to re-source that file and update my shell. is this possible to set-up? thanks paul I'd suggest creating a 'make update' command or something similar that captures the output of the 'cvs update' and post-processes it in whatever way makes you happy. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBeSmc3x41pRYZE/gRAru5AKCUQhOGSB2LImG2SVYTHXk57OYJ0gCfepfZ a20KAN3gXLb9n3UiAjZ4rio= =jWfH -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs-update triggers
Paul, Use the precommand (or postcommand) trigger. http://www.cvsnt.org/manual/postcommand.html This is only available in CVSNT 2.0.58 and later. CVSNT is free (GPL - just like CVS) is available on Linux, Unix, Windows, Mac OS X etc etc. If you are using WinCVS or TortoiseCVS then you are already using it (it comes bundled with those). Since the triggers are executed on the server then you will need to be running CVSNT on the server. http://www.cvsnt.com Regards, Arthur Barrett [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] hello, i would like to setup a trigger for when cvs-update touches a file (updates or merges) in checked out work areas. is there already a mechanism for this? i want it to run a script or set of commands my specific need is that i want to have a shell-rc file in the repository, when someone makes changes to it and then i do an update, i get those changes and therefore would like to re-source that file and update my shell. is this possible to set-up? thanks paul ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Cvs update - file was lost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Andersson [EMAIL PROTECTED] writes: I'm a little worried of one of the warnings when I did a update on a module. We recieved a few warnings like: cvs update: warning: filename was lost U filename The message arises when the information in the CVS/Entries* file(s) have an entry for 'filename' and 'filename is not in the current directory. I understand that you recieve this error messenge if you delete a file in your local sandbox and then do a cvs update. Correct. But if the developer is absolutly sure that he hasn't deleted any local files, what could be the cause of this warning? Filesystem corruption? Someone else removed the file? Some process removed the file? Am I to be worried about the state of the repository? No, the repository state is unrelated to the state of the users local CVS/* files. Please help me out. You should be able to use the source to cvs to prove what happens. The src/classify.c file in the Classify_File function is where the message is generated. Look at the code yourself and see if you can find any other way to get the message you have seen. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBW79Y3x41pRYZE/gRAi0DAJ0Smywf/U2t1Mhkzs1yk5xkyWXQswCgmOFg Y5geGG/AjmkHEeKP5T5/g8Y= =oN+q -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update problem : cannot rename file .new..buildnum to .buildn um
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Viraj Purang wrote: Everytime I try to cvs update a file called .buildnum I get an error : cannot rename file .new..buildnum to .buildnum This is true for all files which have been changed on client workspace and are thus different from the server. What could be the possible problem ? Another interesting issue is that this problem occurs only when I am using a Perl script to do that CVS update.Manual updated are all ok. I would have to sauspect a problem with your perl script. CVS does not use any file naming pattern similar to `.new.*'. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFANREELD1OTBfyMaQRAlWpAKCc1I1HKN1zp5c4sU1rqbx89z6TPgCgyxrp 1uBP1nHYuQufxwMzOW0yr3o= =Bw7+ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Update problem : cannot rename file .new..buildnum to .buildn um
Hi! Have you got the said file or any other file refering to it open in a text editor or an IDE? I have faced this problem when I had the VC++ IDE open with the project file (but not the actual files) and was trying to update the project files (although the DSP and DSW workspace and project files were not updated). If this is the problem, then close the IDE or Text editor completely and try again. Hope this helps. Gagneet -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Viraj Purang Sent: Thursday, 19 February, 2004 10:01 AM To: '[EMAIL PROTECTED]' Subject: CVS Update problem : cannot rename file .new..buildnum to .buildn um I am using a Windows 2003 server (problem also occurs on a Windows 2000 professional laptop). Everytime I try to cvs update a file called .buildnum I get an error : cannot rename file .new..buildnum to .buildnum This is true for all files which have been changed on client workspace and are thus different from the server. What could be the possible problem ? Another interesting issue is that this problem occurs only when I am using a Perl script to do that CVS update.Manual updated are all ok. I did make sure that environment in both the cases is same. Viraj B. Purang Arzoon Inc. ___ 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 update -j problem with merging directories.
Viraj Purang writes: The merge seems to be okay for most of the files, except the 2 new directories which were added to main and r56b0 between build15 and build20 tags. You need to use update -d to get new directories. -Larry Jones Nobody knows how to pamper like a Mom. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS update -j problem with merging directories.
Thanks for the suggestion. It worked for me. Very prompt response. Regards, Viraj Purang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 2:13 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: CVS update -j problem with merging directories. Viraj Purang writes: The merge seems to be okay for most of the files, except the 2 new directories which were added to main and r56b0 between build15 and build20 tags. You need to use update -d to get new directories. -Larry Jones Nobody knows how to pamper like a Mom. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update times
Eric Siegerman writes: Didn't someone say that co locks the whole tree, but update only locks one directory at a time? If they did, they're wrong. Checkout and update both use the same underlying code, so they both do locking the same way (directory at a time). I think admin, commit and the various edit and watch commands are the only things that lock the whole tree; everything else locks a directory at a time. -Larry Jones Please tell me I'm adopted. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update times
On Fri, Nov 14, 2003 at 01:55:55PM -0800, Richard Pfeiffer wrote: The project in question (Proj A) and one I'm using for comparison look like this: Proj A is half the size as Proj B, but did have more directories. I might have to find out just how many more. Proj A took 2m15s to checkout, Proj B took 10m30s. Proj A took 1m14s to update, Proj B to 1m20s. How long do the du -k commands take? (Make sure the data is *not* in the buffer cache.) The time for a du is proportional to total number of filesystem objects, not to directories specifically, but the numbers might still be interesting. So Proj B is twice the Kb, takes 5 times longer to checkout but updates in the same time as Proj A. I'd be interested to know counts of files and directories for both projects. Not sure what use all these numbers would be, but they couldn't hurt :-) I would just write it off to # of dirs, but users claim it was much faster last week. I'll have to check and see if they checked in a bunch of files all in seperate directories, etc. Hmm, it just occurs to me. How about changes on the client side? Could it be that the project-A people (but not the project-B people) installed some app on their Windows boxes that interacts badly with WinCVS? Or in the network? Is there a flaky hub in the project-A room, or is someone there downloading DVDs in the background and saturating their uplink? :-) Could indivdual file or directory sizes have any bearing? Sure, they could be confusing the issue. If project B has N large files, and project A has N small files, I'd expect to see something very roughly like you're seeing -- though the twice the KB, 5 times longer to check out part is mystifying. But that aside, I'd expect the update times to be similar (assuming, of course, that the sandboxes were already up to date). Unlike actually fetching updates, merely checking up-to-dateness isn't proportional to the file sizes. Does a checkout's locking structure differ from an update's locking structure? I wouldn't think so, but if that was true, I would think the co and update times would be proportional for these two projects. Didn't someone say that co locks the whole tree, but update only locks one directory at a time? I don't see how that would affect things, though. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update times
On Fri, Nov 14, 2003 at 12:27:01PM -0800, Richard Pfeiffer wrote: However, we have one project in this repository that now takes 1:58 to checkout and 1:29 to update. It used to update much faster; these 'slow' update times just started occuring. Two stabs in the dark: - Are you on a branch, with large files and/or many revisions between head of branch and head of trunk? Many operations in CVS take longer under such circumstances, because of the way revisions are stored in the ,v file (trunk as reverse deltas from the head; branches as forward deltas from the branch point. See rcsfile(5)). - Does your slow project have a much larger directory:file ratio than your other projects? If so, it could be that locking overhead is dominating the total update time in that project, whereas in your other projects it's the useful work of updating revisions that dominates. CVS's locking overhead is proportional to the number of directories (not files) being operated on. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update times
Thanks Eric. I had actuallythoughtof both of those and took quick looks: 1) There are no branches as of yet, so that nixed that thought! 2) I think the second thought is the one I need to investigate further. Just wanted to see if the list concurred, or had ideas I overlooked. I initially took a quick look at the directory structure while doing a du -k to see how large theproject was getting. The project in question (Proj A)andone I'm using for comparison look like this: Proj A is half the size as Proj B, but did have more directories. I might have to find out just how many more. Proj A took 2m15s to checkout, Proj B took 10m30s. Proj A took 1m14s to update, Proj B to 1m20s. So Proj B is twice the Kb, takes 5 times longer to checkout but updates in the same time as Proj A. I would just write it off to # of dirs, butusers claim it was much faster last week. I'll have to check and see if they checked in a bunch of files all in seperate directories, etc. Could indivdual file or directorysizes have any bearing? Does a checkout's locking structure differ from an update's locking structure? I wouldn't think so, but if that was true, I would think the co and update times would be proportional for these two projects. Thx, -R Eric Siegerman [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2003 at 12:27:01PM -0800, Richard Pfeiffer wrote: However, we have one project in this repository that now takes 1:58 to checkout and 1:29 to update. It used to update much faster; these 'slow' update times just started occuring.Two stabs in the dark:- Are you on a branch, with large files and/or many revisionsbetween head of branch and head of trunk? Many operations inCVS take longer under such circumstances, because of the wayrevisions are stored in the ,v file (trunk as reverse deltasfrom the head; branches as forward deltas from the branchpoint. See rcsfile(5)).- Does your slow project have a much larger directory:fileratio than your other projects? If so, it could be thatlocking overhead is dominating the total update time in thatproject, whereas in your other projects it's the useful workof updating revisions that dominates. CVS's locking overheadis proportional to the number of directories (not files)being operated on.--| | /\|-_|/ Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]| | /It must be said that they would have sounded better if the singerwouldn't throw his fellow band members to the ground and toss thedrum kit around during songs.- Patrick Lenneau___Info-cvs mailing list[EMAIL PROTECTED]http://mail.gnu.org/mailman/listinfo/info-cvs Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS update + access via ssh.
Mensaje citado de [EMAIL PROTECTED] el 10/09/2003 10:00: When I ran ssh -v I noticed that the generated key was not accepted by the remote server. Any ideas? The directory .ssh must be chmoded 700 (only owner can cd into it), while the file authorized_keys inside can be chmoded whatever you like. This, on the remote side. On the local side, check that permissions for the private key file are proper. In my case, id_rsa is chmoded 600. Maybe, also, one of the users has listed a valid shell at /etc/passwd, while the other has not. Good luck. Regards, Ismael -- Ismael Valladolid Torres, Technical Support Oberthur Card Systems, Bajo Oficina C, Edificio Valrealty B 28023 La Florida - Madrid (Spain) - http://www.oberthurcs.com/ Tel. +34 917 355 461 - Fax: +34 917 355 453 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update info
Rich, cvs update update.txt ? cvs update | less ? Steve On Thu, 2003-02-20 at 18:57, richard blair wrote: I perform a cvs update on a large directory structure, and a conflict happens, but the file it happened on is too far up to scroll to. Does anyone know how to retrieve that information? In other words, how do I find out which files were in conflict after I have performed an update? Rich -- Steven Tryon, CIBER @ Xerox Webmaster, Xerox Global Service Net 8*221-7719 / 585-231-7719 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update info
Try using the attached perl script. It cleans up the display quite nicely, with a summary at the end for things like conflicts, files in the way, etc. I perform a cvs update on a large directory structure, and a conflict happens, but the file it happened on is too far up to scroll to. Does anyone know how to retrieve that information? In other words, how do I find out which files were in conflict after I have performed an update? Rich ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs cvs_update_display.pl Description: Binary data ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update info
You don't say what operating system you are using, but whatever it is you should be able to redirect the output to a file, for example by doing: cvs update info.txt Then you can browse the file with whatever text editor or viewer you like. If you are using a Unix-alike you could use 'more info.txt' to paginate the output, or on a WinDoze DOS client, use 'moreinfo.txt'. Alternatively, if you are using a WinDoze client, you could try changing the screen buffer size (available through the 'properties' for the shortcut you use to invoke the command line) to something suitable, but this will depend on what is supported by your version of the OS. HTH Mark Cooper Reuse Manager Microlise Limited http://www.microlise.co.uk mailto:[EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update info
richard blair [EMAIL PROTECTED] writes: I perform a cvs update on a large directory structure, and a conflict happens, but the file it happened on is too far up to scroll to. Does anyone know how to retrieve that information? In other words, how do I find out which files were in conflict after I have performed an update? If you run 'cvs -n update' again, the files that are in conflict will be listed. You may also run the 'cvs status' command to see files that are in conflict (File had conflicts on merge). Enjoy! -- Mark ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update lag
[EMAIL PROTECTED] writes: We are seeing major lag when issuing cvs update . in the root dir. of any of our dev's checkouts. (Major lag as in 5 mins. or MORE) A trace shows a long wait @ - unlink_file(CVS/Entries.Log). Our CVS server is FreeBSD. The main clients are Solaris and Linux. Any clues/hints/pointers of where I should be looking for the lag? How big is the tree you are checking? Recall that the server builds up a copy of the impacted files in /tmp/cvs-servrandom and that at the end of the cvs update it will need to do the equivalent of a rm -fr /tmp/cvs-servrandom to remove any files that have collected on the server side of the connection. -- Mark ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update
[EMAIL PROTECTED] writes: The platform is windowsNT. It's a client server mode and I'm using cvsnt_1.11.1.3. Is cvsnt the client as well as the server? (I don't know much about cvsnt -- it's a separate line of development from the standard CVS.) If so, perhaps you've found a bug, but I still think the most likely problem is that your working directory is on a network share of some kind that's not working right. As far as CVS is concerned, it sounds like you're not doing anything wrong. -Larry Jones I think we need to change the rules. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update
[EMAIL PROTECTED] writes: MIME-Version: 1.0 Content-Type: multipart/alternative; Please don't send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! Cvs[update aborted]: cannot rename file .new.delludf.jar to delludf.jar: No such file or directory. Is this because of the .jar extension? No. Most likely, your local directory isn't really local and there are bugs in your network file system (or at least incompatibilities with CVS's expectations). Another possibility is that your CVS wasn't configured correctly for your platform. It would help to know what platform you're running on, whether you're running in local mode or client/server mode, and what version(s) of CVS you're using. -Larry Jones What better way to spend one's freedom than eating chocolate cereal and watching cartoons! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs update
The platform is windowsNT. It's a client server mode and I'm using cvsnt_1.11.1.3. I have some jar files that need to be updated so on the server side I've added the .jar extension to the .cvswrapper file. And then I import the file using jcvs. But I think somehow the files got corrupted cos I cannot open them using win zip also on update. On update I'm not using any special switch or flag (cvs update moduleName). Is this the correct way to handle jar files in cvs. I'm really really new to cvs please help. I'll appreciate any help on how to handle jar file Gunjan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 4:23 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: cvs update [EMAIL PROTECTED] writes: MIME-Version: 1.0 Content-Type: multipart/alternative; Please don't send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! Cvs[update aborted]: cannot rename file .new.delludf.jar to delludf.jar: No such file or directory. Is this because of the .jar extension? No. Most likely, your local directory isn't really local and there are bugs in your network file system (or at least incompatibilities with CVS's expectations). Another possibility is that your CVS wasn't configured correctly for your platform. It would help to know what platform you're running on, whether you're running in local mode or client/server mode, and what version(s) of CVS you're using. -Larry Jones What better way to spend one's freedom than eating chocolate cereal and watching cartoons! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs update
hi, It will be the last committed timestamp according to me... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jayashree Sent: Friday, September 06, 2002 12:13 PM To: [EMAIL PROTECTED] Subject: cvs update Hi, $cvs status a.c File: a.cStatus: Locally Modified Working revision:1.40Mon Sep 2 20:46:00 2002 Repository revision: 1.40/home/cvs/a.c,v What does the time stamp Mon Sep 2 20:46:00 2002 mean? Is that the checkout/update time or checkin time of the file? Regards Jayashree *** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *** ___ 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 update (cvs status shows CVS/Entries cached date/time)
Jayashree wrote: Hi, $cvs status a.c File: a.cStatus: Locally Modified Working revision:1.40Mon Sep 2 20:46:00 2002 Repository revision: 1.40/home/cvs/a.c,v What does the time stamp Mon Sep 2 20:46:00 2002 mean? Is that the checkout/update time or checkin time of the file? Regards Jayashree cvs status a.c ls -l a.c #note timezone to GMT effect sleep 60;touch a.c cvs status a.c ls -l a.c #note no change from above cp a.c a.c.bak sleep 60;cp a.c.bak a.c;date grep a\.c CVS/Entries cvs status a.c;date grep a\.c CVS/Entries cvs status a.c;date ls -l a.c #note timezone to GMT effect #A1: last time the local file was noted by cvs to have been written. #A2: last time the local file was written. #where written can be by cvs [checkout|update], save from your editor, cp. cvs version Concurrent Versions System (CVS) 1.11 (client/server) CVS Gurus Is this supposed to report the cached value, instead of the filesystem value which it caches during the command (kind of surprised me) Unfortunately http://www.cvshome.org/docs/manual/cvs_17.html#SEC155 and http://www.cvshome.org/docs/manual/cvs_10.html#SEC84 have the only detailed Cederqvist info I could find on cvs status and neither documents the time field for the Working revision. So do we have an annoyance level buglet? -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update
Jayashree writes: $cvs status a.c File: a.cStatus: Locally Modified Working revision:1.40Mon Sep 2 20:46:00 2002 Repository revision: 1.40/home/cvs/a.c,v What does the time stamp Mon Sep 2 20:46:00 2002 mean? Is that the checkout/update time or checkin time of the file? Neither; or both, depending on how you look at it. It's the timestamp the file had the last time CVS checked that it was identical to revision 1.40. -Larry Jones Don't you hate it when your boogers freeze? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update, empty dirs, permission denied
:If someone adds a empty directory to the cvs project, on the cvs server :the directory is there. To keep an emtpy directory insert a dummpy file in it called .keepme or something like that. -- sherzodR ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update and file date
Mirco Bova wrote: HEllo all, I noticed that when I delete a file from the working directory to restore it (i.e. I run cvs update on the entire directory) The file is restored but the modification date of the file is the current date/time instead the date/time when it was last commited or the original mod. date/time. This breaks my make chain leading to unwanted rebuild! Is there any way to avoid this? I don't think so. Updating a file to old or new revisions means the file has changed, and all changes should force a rebuild for the dependency tree to remain consistent. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update and file date
On Thu, Jul 11, 2002 at 12:02:29PM +0200, Mirco Bova wrote: I noticed that when I delete a file from the working directory to restore it (i.e. I run cvs update on the entire directory) The file is restored but the modification date of the file is the current date/time instead the date/time when it was last commited or the original mod. date/time. This breaks my make chain leading to unwanted rebuild! This behaviour is intentional, and the reason is specifically to force a rebuild. In your particular case, the rebuild might have been unnecessary, but in general it's very necessary. Suppose foo.o was based on rev. 1.5 and you'd just gone cvs update -r1.4 foo.c. Or, closer to home, suppose foo.o was built from a modified version of 1.5 (i.e. with not-yet-committed changes), and you decided to revert the changes by doing exactly what you in fact did. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update from 1.10.7 - 1.11.1p1 or later
Hello ! I think, we will have to upgrade our CVS-server-binary (UNIX) in the nearest future, because we will need enhanced commands like 'rdiff', 'rlog', and so on ... What happens, if I upgrade my CVS-server from 1.10.7 to 1.11.1p1, what should I take care of, especially with locally checked out copies and history files ? Is it just as easy like copying the new version over the old one, or will I have to run conversion-utilities, to make my files compatible with the new CVS ? Once you've copied it over, do a cvs init. I don't think it will do anything in this case, but it's a good habit to develop when upgrading CVS. Other than that, yes, it is just that easy. David H. Thornley| If you want my opinion, ask. [EMAIL PROTECTED] | If you don't, flee. http://www.thornley.net/~thornley/david/ | O- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS update bug
On Thu, 4 Apr 2002, Kaz Kylheku wrote:
Date: Thu, 4 Apr 2002 11:31:08 -0800 (PST)
From: Kaz Kylheku [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [self-mail] CVS update bug
If you add files, and then switch to a branch, the files are not made
sticky to that new branch. A subsequent commit succeeds, but for these
added files it goes to the wrong place. This breaks the classic CVS
use case of hacking on some changes, and then later deciding to switch
to a branch and commit there instead. It was reproduced with CVS 1.11p1.
Here is a patch, against the bleeding edge CVS. Here is how it
works.
Firstly, in tag.c it defeats the stupid check that prevents tagging if
there are one or more locally added files. If an entry has no RCS
version file, we check its status. If its status is T_ADDED, then we
simply skip the file.
Secondly, in tag.c, there is a second check when an added file is being
tagged. We change the return value here to pretend that we did tag.
If we don't, it causes a problem in the case that the added files
are the *only* ones in the given directory. The problem is that the
tag won't then be written to val-tags, and CVS won't know that the
tag exists.
Lastly, in update.c, we add a case for T_ADDED. Register() is now
called to register the file in CVS/Entries. The version is specified
as the hard-coded string 0, mimicking what cvs add does.
So now you can create an empty project, cvs add a file, then
cvs tag -b to create a branch, cvs update -r to switch to that branch,
and then commit the added file there.
? cvs.diff
Index: tag.c
===
RCS file: /cvs/ccvs/src/tag.c,v
retrieving revision 1.94
diff -u -r1.94 tag.c
--- tag.c 6 Jun 2001 19:43:04 - 1.94
+++ tag.c 5 Apr 2002 00:31:00 -
@@ -420,7 +420,7 @@
char *xdir;
Node *p;
Vers_TS *vers;
-
+
if (check_uptodate)
{
Ctype status = Classify_File (finfo, (char *) NULL, (char *) NULL,
@@ -466,11 +466,18 @@
p-delproc = tag_delproc;
if (vers-srcfile == NULL)
{
-if (!really_quiet)
+int result = 1;
+ Ctype status = Classify_File (finfo, (char *) NULL, (char *) NULL,
+ (char *) NULL, 1, 0, vers, 0);
+
+ if (status == T_ADDED)
+ result = 0;
+
+if (result == 1 !really_quiet)
error (0, 0, nothing known about %s, finfo-file);
freevers_ts (vers);
freenode (p);
- return (1);
+ return (result);
}
/* Here we duplicate the calculation in tag_fileproc about which
@@ -958,7 +965,7 @@
if (!quiet)
error (0, 0, couldn't tag added but un-commited file `%s', finfo-file);
freevers_ts (vers);
- return (0);
+ return (1);
}
else if (version[0] == '-')
{
Index: update.c
===
RCS file: /cvs/ccvs/src/update.c,v
retrieving revision 1.197
diff -u -r1.197 update.c
--- update.c8 Jul 2001 20:51:46 - 1.197
+++ update.c5 Apr 2002 00:31:00 -
@@ -770,6 +770,12 @@
retval = checkout_file (finfo, vers, 0, 0, 1);
break;
case T_ADDED: /* added but not committed */
+ /* Reregister to set any sticky tag, so when the
+ add is committed, it goes to the right place. */
+ Register (finfo-entries, finfo-file,
+ 0, vers-ts_rcs,
+ vers-options, vers-tag,
+ vers-date, (char *)0);
write_letter (finfo, 'A');
retval = 0;
break;
--
Meta-CVS: solid version control tool with directory structure versioning.
http://users.footprints.net/~kaz/mcvs.html
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS update bug
[ On Thursday, April 4, 2002 at 16:38:32 (-0800), Kaz Kylheku wrote: ] Subject: Re: CVS update bug Firstly, in tag.c it defeats the stupid check that prevents tagging if there are one or more locally added files. If an entry has no RCS version file, we check its status. If its status is T_ADDED, then we simply skip the file. That's not exactly a stupid check -- an added file _is_ a modified file until it has been committed. That check should only be disabled if 'cvs tag -c' was given (i.e. check_uptodate is set) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS update bug
On Thu, 4 Apr 2002, Greg A. Woods wrote: Date: Thu, 4 Apr 2002 21:15:30 -0500 (EST) From: Greg A. Woods [EMAIL PROTECTED] Reply-To: CVS-II Discussion Mailing List [EMAIL PROTECTED] To: Kaz Kylheku [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: CVS update bug [ On Thursday, April 4, 2002 at 16:38:32 (-0800), Kaz Kylheku wrote: ] Subject: Re: CVS update bug Firstly, in tag.c it defeats the stupid check that prevents tagging if there are one or more locally added files. If an entry has no RCS version file, we check its status. If its status is T_ADDED, then we simply skip the file. That's not exactly a stupid check -- an added file _is_ a modified file until it has been committed. The check I disabled (or rather altered) is not the local modification check. It's a separate check for the a missing RCS file. That check should only be disabled if 'cvs tag -c' was given (i.e. check_uptodate is set) That check is not conditional to -c; it happens without -c. If you tag over some locally added file without -c, you will get the error ``nothing known about file'' and the tagging will fail. The old logic was: if (no RCS file) problem My fix has this: if (no RCS file) if (locally added) okay else problem -- Meta-CVS: solid version control tool with directory structure versioning. http://users.footprints.net/~kaz/mcvs.html ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update to branch with -f option
[EMAIL PROTECTED] writes: Each branch has a few developers working on a handful of files. A developer working in a branch performs a checkout for the branch with the -f option, giving him an entire repository to work from consisting of the branched files, and the remainder of the repository from the main trunk. This developer then commits his changes to the branch for the other developers working in his branch. The other developers working in that branch then perform an update to the branch with the -f option, again giving them the files committed by other developers in that branch and the remainder of the repository from the main trunk. This method works well for us, except when the -f option is used, I would like to get the non-matching files from a tag, rather than from the main trunk (eg HEAD). Branch the entire repository and stop using -f. Branches are cheap, particularly if you never commit anything on them. And by branching everything, you can branch wherever you want to get particular revisions of certain files (e.g., at a particular tag). -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update to branch with -f option
Larry Jones wrote: [EMAIL PROTECTED] writes: Each branch has a few developers working on a handful of files. A developer working in a branch performs a checkout for the branch with the -f option, giving him an entire repository to work from consisting of the branched files, and the remainder of the repository from the main trunk. This developer then commits his changes to the branch for the other developers working in his branch. The other developers working in that branch then perform an update to the branch with the -f option, again giving them the files committed by other developers in that branch and the remainder of the repository from the main trunk. This method works well for us, except when the -f option is used, I would like to get the non-matching files from a tag, rather than from the main trunk (eg HEAD). Branch the entire repository and stop using -f. Branches are cheap, particularly if you never commit anything on them. And by branching everything, you can branch wherever you want to get particular revisions of certain files (e.g., at a particular tag). The disadavantage to branching the entire repository is that you have to do unnecessary maintenance to keep up with changes in areas that you aren't changing. So, when you say branches are cheap, I'm not sure that you're accounting for the entire cost. The overhead in the CVS implementation is fairly cheap (once you have spent the time to create them), but the total cost in making sure you have the right content can be considerable. (This is one useful thing about ClearCase's config specs - it enables you to select the appropriate version of various parts of your tree.) The way we've worked around this (which is admittedly a kludge, but it gets what we need) is to define modules which correspond to the populations of the various branches and then do a series of checkouts to construct the versions you need. If you have cases where the modules overlap in some way, always check out the default versions first to set up the complete tree and then successive checkins will replace the more specific files that you want. It doesn't work if you do it in the opposite order because CVS doesn't have a good way to express the complement of a module. Running update in this hybrid workspace generally does what you want because for each file it updates the version according to the sticky tags for that file. Adding new files and directories in this situation does take special care to make sure things are going to the right branch. Realize also, that when you want to update your base versions, you have to completely reconstruct the workarea - the checkout ordering is extremely important. Like I said, this isn't pretty, but it is possible. The complexity involved has more to do with the limitations of module naming than having the ability to default to a tag. I've raised the issue of -f behavior before in this forum and the general consensus is that it doesn't work in any useful fashion. Hope this helps, =Bob= Bob Bowen [EMAIL PROTECTED] Process Engineering (952)876-4635 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update to branch with -f option
Bob Bowen wrote: Larry Jones wrote: Branch the entire repository and stop using -f. Branches are cheap, particularly if you never commit anything on them. And by branching everything, you can branch wherever you want to get particular revisions of certain files (e.g., at a particular tag). The disadavantage to branching the entire repository is that you have to do unnecessary maintenance to keep up with changes in areas that you aren't changing. Sorry, but I don't understand this. Could you detail what you mean by maintenance to keep up with changes in areas that you aren't changing? Perhaps an example would clear things up for me. I'm curious because I've never run into any problems with branching beyond the scope developers *believe* changes will be limited to. Yet, doing so eliminates the frequent iterations of branching (and the bottleneck of having to stop development until the request and implementation of the branch is complete) that we would've run into otherwise. thanks, dtayl ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Tuesday, February 26, 2002 at 16:19:11 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour --- Forwarded mail from [EMAIL PROTECTED] [ On Tuesday, February 26, 2002 at 10:27:23 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour inclusion, the relationship between the two files becomes variable. In the event that a file is moved into a shared module and at a later time the target file's history is needed (from within a module other than the original one), there's no record of its original module in the comment. But that is definitely not the general case. It may not be the absolute most common case (trivial module declarations are), but it falls well within the normal bounds of modules database usage. No, not even the normal bounds -- only the possible bounds. Actually, using trivial modules exposes the problem as well. Consider the following three module definitions: top project part1-mod project/part1 part2-mod project/part2 Now perform this sequence: cvs checkout top cd top/part1 mv some-file ../part2 cvs rm some-file ( cd ../part2 cvs add some-file ) cd .. cvs commit -m moved some-file to ../part2/somefile cd .. cvs release top cvs checkout part1-mod cd part1-mod cvs log some-file The last thing that appears in some-file's history is moved some-file to ../part2/somefile. This is totally meaningless because there is no ../part2 directory, and the user has no way to determine where it is. This is why the rename feature MUST record the location of the RCS file, so that the user can find it with something like cvs rlog. There have been many discussions, and there's even documentation in several places, telling all who'll read it that using non-trival modules declarations is like dancing with the devil -- you will encounter problems! Side note: I can find only one reference to a problem with the modules database at all in the Cederqvist manual. And it says to not to rely on misleading progress messages during checkout of ampersand modules. There is no mention of the problems that have been discussed at length in this forum in the past. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
OT RE: CVS Update Behaviour
While this conversation has been entertaining, I think it's time to take it off-list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 27, 2002 10:37 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: CVS Update Behaviour [ On Tuesday, February 26, 2002 at 23:51:29 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour My point was that very few programmers, including the seasoned toolsmiths who read this list, know and regularly use all of the tools at their disposal. Then you have confirmed that your point is irrelevant, just as I said it was. Yes, some of the tools I listed are nearly worthless (or at least have better alternatives). And in my world, patch also falls into that category. (I don't know why Greg seems to have a problem with this fact.) I have no problem with the fact you consider 'patch' to be useless for your needs. I do have a very major problem with the fact that you don't have any alternative that's better for your needs. This is clearly why you've had so much problems with file renames. Clearly you should be using 'patch' (or desparately trying to find something equally capable) because it solves problems you've apparently left un-solved and which you've continually whined and moaned about in this forum for literally years now. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ 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 Update Behaviour
[ On Wednesday, February 27, 2002 at 01:04:34 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour Actually, using trivial modules exposes the problem as well. Consider the following three module definitions: top project part1-mod project/part1 part2-mod project/part2 You've created an alias without really telling CVS about it. This is like aliasing a pointer in C. How could even a magical new CVS which had full rename support understand what you intend? Not even the CVS manual suggests using such ambiguous (broken) constructs (though older examples, and IIRC the original paper, do suggest such dangerous things) I've only once ever created modules like above, and in that case I was very careful to document that the 'top' module was only ever to be used by the release manager. Side note: I can find only one reference to a problem with the modules database at all in the Cederqvist manual. And it says to not to rely on misleading progress messages during checkout of ampersand modules. There is no mention of the problems that have been discussed at length in this forum in the past. Indeed the CVS manual is seriously lacking w.r.t. documenting the implications and limitations about modules support. I've never claimed otherwise. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
Hey - Can you guys take this offline? thanks! donald On Wed, Feb 27, 2002 at 11:37:10AM -0500, Greg A. Woods wrote: [ On Tuesday, February 26, 2002 at 23:51:29 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour My point was that very few programmers, including the seasoned toolsmiths who read this list, know and regularly use all of the tools at their disposal. Then you have confirmed that your point is irrelevant, just as I said it was. Yes, some of the tools I listed are nearly worthless (or at least have better alternatives). And in my world, patch also falls into that category. (I don't know why Greg seems to have a problem with this fact.) I have no problem with the fact you consider 'patch' to be useless for your needs. I do have a very major problem with the fact that you don't have any alternative that's better for your needs. This is clearly why you've had so much problems with file renames. Clearly you should be using 'patch' (or desparately trying to find something equally capable) because it solves problems you've apparently left un-solved and which you've continually whined and moaned about in this forum for literally years now. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ 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 Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour Renames are not usually a requirement of maintenance, but they are a requirement of new development. Bug fixes are done during maintenance, and merged into new development. That means that bug fixes are merged into new development, often after prior new development involved renames. This mode of operation is common! Sometimes renames are done on a task branch and folded into the next release It is extremely rare for bug fix merges to work automatically with CVS commands alone, with or without any renames getting in the way. First of all, I don't believe that I have implied that merges complete automatically in the general case. There will be occasional conflicts that require manual intervention, but that's the case with any merge in which there are changes committed on both branches. But it has been my experience that they work as well as merges performed while updating in new development. This is because bug fixes tend to be small and localized, within established artifacts that aren't modified during new development. (In those rare events where there is a conflict, the new development usually involves additions, rather than changes and deletions. I'm not sure if that fact makes life easier or harder, but it's worth pointing out that observation.) If the maintenance programmers don't understand explicitly what they're doing then they will not succeed. If you've seen such problems so often then you've been working with people who do not understand what they are doing, and that's very dangerous for the product they're working on. There's a distinction between maintenance programmer who make bug fixes on maintenance branches, vs. new development programmers who merge bug fixes from the maintenance branches into the next release. It so happens that in my world, the two sets of programmers are the same people, but that's not the general case. Anyway, the people performing the merge are expected to know what they're doing with respect to making sure that the result of the merge meets its specification, i.e. contains both the bug fix and the new functionality without introducing new bugs. They're pretty good at that. and I've seen this more often than I care to remember on vendor branches. huh? what do vendor branches have to do with this? If you don't understand that you have to manually move changes between files that have been renamed by the vendor then you should not be messing with such complicated things that you do not understand. Vendor branches are no different from any other branch, as far as renames are concerned. Renames performed on the vendor branch must migrate to other branches when merges are performed. When's the last time anyone's used tsort(1), join(1) or fmt(1), or even cut(1), paste(1) or fold(1), and Greg's favorite ed(1), even on this list that's full of toolsmiths? Hmmm... I don't use fmt or fold, or cut paste very often, but that's because I use better tools to do what they can do I certainly do know of their existance though, and what they could do if I needed them. In other words, even you don't use all of the tools that are at your disposal. You just the ones you prefer to use. Sounds familiar. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Sunday, February 24, 2002 at 20:13:51 (-0800), Noel Yap wrote: ] Subject: Re: CVS Update Behaviour --- Greg A. Woods [EMAIL PROTECTED] wrote: patch has been a standard tool in unix development for nearly two decades now. Prior to that the commonly used tool that can do the exact same job with only slightly less success and using the exact same tool to create the diff, was called 'ed'. It's been around for over three decades now. Time to crawl out from under your rock and get with the program Paul! Greg, your experience is not the norm. Most developers, possibly sadly, aren't familiar with the whole gamut of available commands. Any so-called developer who is not familiar enough with the tools used daily to do his or her job is not really a developer. Some idiot might pay such a person to be a developer, but that doesn't make them a developer in the real world -- only in the imaginations of the employer and the employee. Someone not familiar enough with the tools used daily to do his or her job, etc. etc. I think the point that Noel and I are trying to make is that tools like patch are not used daily by the developers to get their jobs done. It just isn't needed and remain unknown for that reason. The tools I refer to are very plainly documented in the CVS manual and the CVS unix-style manual page. Even a simple skim through the manual page for GNU diff (the diff used with CVS, though unfortunately it's not shipped with CVS) will also reference the manual page for 'ed' and 'patch', and gives quite strong hints at how to use these tools to mechanically re-apply changes with them. Anyone claiming to be a developer but not able to figure this out on their own really needs to be smacked with something a lot harder than a clue-by-4! Why bother with patch when merge is better? Or even better yet, cvs update? Furthermore, to do a proper merge, one needs three files. I think patch is incomplete since all the information between the ancestor revision and the current file is completely lost. You're on strange drugs again my friend. The patch input file will only be incomplete if you fail to generate it properly. One of the first lines in the output of man patch hints at this: patch - apply a diff file to an original Uh hug. Diff and diff3 produce diff files. Patch takes the output of diff _or_ diff3 as input. Interesting, I just read the man page for patch again, and it doesn't mention diff3. According to this, all that patch does is it takes the difference between one file and another, applies the difference to a copy of the first file to produce a copy of the second file. This is a simple 2-way merge, which we all know is inferior to 3-way merges because they don't account for situations in which the delta is applied to something that isn't identical to the first file. Since, when merging, one doesn't apply a diff file to _the original_, patch isn't really the ideal tool to do it. Well, first off, it seems you've got to learn a wee bit more about how 'diff' and 'patch' work conceptually before you'll realise that to an original does not mean what you think it means. Every newbie may suffer the same mis-interpretation, but I'm not sure that means the phrase is wrong in the context it is in. After reading the man page again, I believe that original means a file that is bit-for-bit identical to one of the files involved in creating the difference that is fed to the the patch program. However, if the difference is presented in the context of surrounding lines, then the patch program can be instructed to fudge a little on the context. But my experience with it does not indicate that it fudges at all with the actual delta, but rather creates a second file containing the changes it could not apply due to conflicts. It also refuses to apply a difference if it has to fudge too much. I personally find diff3's mark-ups to be easier to work with than a bunch of .rej files. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Sunday, February 24, 2002 at 20:24:15 (+0100), Nagy Gabor wrote: ] Subject: Re: CVS Update Behaviour I think renaming and moving files accross directories is nice to have. I don't think it is necessary, in a way that I can live without this feature. But if I think that this would make my life easier, don't try to tell me, I shouldn't _think_ that. You should not be using CVS if you think it should automatically handle all manner of renames and hide all the resulting issues from the user. CVS is designed for use in those scenarios where using RCS alone would cause your developers to rip the hair from their scalps (and/or from the scalps of their colleagues). RCS clearly only manages files -- on its own it doesn't even have a way of removing a file, except by not tagging it for inclusion in release, or not branching it. CVS already handles file renames in an adequate manner, with much more support than RCS (files can be removed from normal view!). It does not try to hide renames from the user though. This is a good thing. There are many issues fall out of renaming files. These issues are generally not well understood and the users of CVS need to be well aware of renames that have happened so that they can deal with these issues properly. When I discovered cvs did not know this, I was puzzled, and sad. I am puzzled and sad that you could not figure this out on first meeting and learning CVS. It really should be as self evident as it is well documented in the manual. And I still long for the mapping of entities to filenames. What I would like to see, is a kind of Inode way of storing things in the repository. Multiple names of the same entity, renames, anything. And one representation You really need to learn more about how CVS works internally. If you had chosen CVS because RCS was insufficient for your needs then I think you would be happy not to have such a mapping layer. CVS handles renames by way of removing and adding files. No history is lost, but also no complications are introduced by such a mapping layer. Lastly: If there is something that doesn't hurt you, (you can cat a file to another name and rm the old one, don't have to mv, so you can do it as you always did) but others would like to have that particular feature, why object? Why do you want to judge if it is rightfully needed by others? Implementing a mapping layer in CVS will hurt CVS. It is impossible to implement such a mapping layer without destroying backwards compatability. CVS is highly valued by many of its users because it simply automates what can be done tediously with RCS alone. This means that CVS does not implement a proprietary repository format that cannot be moved with ease to other tools that understand the same format, and indeed the RCS format is widely understood both by tools and by humans. It is stable and quite capable for the basic requirement of the job. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] [ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour huh? what do vendor branches have to do with this? If you don't understand that you have to manually move changes between files that have been renamed by the vendor then you should not be messing with such complicated things that you do not understand. It seems to me that the question is not understanding, but whether it is desirable. It would be nice if CVS would track vendor renames, but it would have to be able to figure out vendor renames, and in any case the sources we track tend to be kept in CVS anyway, so the supplier is unlikely to rename things gratuitously. I had one that did rename things gratuitously. Actually, I had two. One of them changed hyphens to underscores in directory names, the other performed the following swap: a/b/c/d -- a/c/b/d Both of these are conceptually simple changes, and the contents of of the directories were not themselves renamed and contained substantially the same bits. It was rediculous to have to fragment my version histories for these large trees just for this, but it was the CVS way and it had to be done. Sun did the first of these to me in their documentation for the Solaris operating system. Sun and USL did the second one to me with the Solaris and System V kernels. The workaround we employed for both of these was to create new modules, but everyone exposed to these was very unhappy with that solution specifically due to the fragmented version history as well as the need to keep two sandboxes and laboriously merge local changes into the vendor drops. Performing the merge was very time-consuming, and using cvs update instead would have reduced the effort by about 40%. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Monday, February 25, 2002 at 10:46:14 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour --- Forwarded mail from [EMAIL PROTECTED] Free software development depends critically on patch. Just about anyone involved in it must know how to produce and apply patches. Most of the people I work with don't produce free software, or at least they don't collaborate in producing it. That's totally irrelevant. If they're doing any kind of development these days then they really _MUST_ keep themselves aware of free software, and especially of free software development tools. That goes double if they're using a free software tool in a central part of their development process! No, they must keep themselves up with the tools they use, regardless of whether or not they are free ones. I do produce free software, and I still use patch only once in 2-3 years. You do use 'patch' every time you do a merge with CVS, and indeed almost every time you do a cvs update from a remote server! Sure it's built into the CVS client now, but it still tells you with the 'P' it shows. Really? I thought that CVS fell back to something else if patch was unavailable In any case, *I* use cvs update and I don't care what goes on beneath the covers as long as the result is what I expect. More importantly you also use free software, obviously, and if you are avoiding using 'patch' by manually applying all the disributed diffs you hopefully use with that free software then you really should learn to use 'patch' -- it makes such tedious work far less error-prone. I just download the new distribution and check it in. For me, that's much faster, easier, and reliable than exporting, patching, and importing. As an obvious side-effect of this practice, I don't have to use patch. That applies to most of my coworkers as well. BTW, 'patch' is a _standard_ Unix tool. It's documented in The Single UNIX Specification, and it will be in IEEE Std. 1003.2b. Fine. So are cut and paste. You don't use them (preferring to use something else that better fits your need, see quote below), so why should my colleagues use patch if they prefer using something else that better fits their need? The free software community remains a surprisingly small one, compared to the total size of the industry, and it's my job to support people who are not part of that small community. So many people in the software industry would like to think. However if you're using CVS (and maybe other core tools like GCC and such), then you're either hiding from reality, or purposefully subverting it, or both. I.e. if you're using CVS then you are part of that community, like it or not. There's the free software community in the sense of people who use free software, and there's the free software community in the sense of people who publish free software. It was clear in the context of the two quotes to which you refer that I meant the latter of the two. In that small community, I don't dispute (in writing) that patch is a critical tool. I do claim that in the larger community of users, patch is not a requirement. And don't split hairs claiming that one is a proper subset of the other and how can it be critical on the one hand and not on the other; you know what I mean. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Sunday, February 24, 2002 at 22:09:31 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour Hmmm... Let's recap: cp $1 $2 cvs rm -f $1 cvs add $2 cvs commit -m moved $1 to $2 $1 $2 Where is the *location of the RCS file* recorded in the comment? You don't need to know the location of the RCS files -- that's internal to CVS and not for human consumption. It's of no use in a client-server invocation in any case. You don't need to know it because of course the pathnames given in the parameters $1 and $2 will always have a fixed relationship to each other and that relationship is sufficient to transform either into the pathname necessary for use with 'cvs log' or 'cvs update -p', etc. no matter where the reader starts from (so long as they are within a working directory for the same module and so long as they know where they are with relation to the log they're currently reading). This is really very trivial pathname stuff -- I don't understand why you even think it's an issue. Obviously there's a bit more of a trick necessary than my example alludes to since 'cvs add' doesn't yet work for relative pathnames! ;-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
On 02-Feb-25 17:54, Greg A. Woods wrote: When I discovered cvs did not know this, I was puzzled, and sad. I am puzzled and sad that you could not figure this out on first meeting and learning CVS. It really should be as self evident as it is well documented in the manual. That's where I found it. I figured it out the first time I tried to use this feature. You really need to learn more about how CVS works internally. Maybe. If you had chosen CVS because RCS was insufficient for your needs then I think you would be happy not to have such a mapping layer. CVS handles renames by way of removing and adding files. No history is lost, but also no complications are introduced by such a mapping layer. I never used RCS. I was looking for a version control system for my own stuff after using PVCS in my job. I also used VSS later for something else. For my Linux CVS appeared to be the best choice, supported, documented, lot of people using it. If I don't use CVS, which version control system would you suggest which is free, and does all what I want? (OK, I'll check metacvs out) Implementing a mapping layer in CVS will hurt CVS. It is impossible to implement such a mapping layer without destroying backwards compatability. I don't know the internals enough. I don't really care about backward compatibility. Surely it has to be a possibility for people who need that. CVS is highly valued by many of its users because it simply automates what can be done tediously with RCS alone. This means that CVS does not implement a proprietary repository format that cannot be moved with ease to other tools that understand the same format, and indeed the RCS format is widely understood both by tools and by humans. It is stable and quite capable for the basic requirement of the job. OK. I don't know how hard it would be to implement this, what the implications were. If you say, it would be inefficient, I would accept that answer. If you say that you don't need that feature, that's silly. Thanks for the answer Gee ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Greg A. Woods [EMAIL PROTECTED] wrote: [ On Sunday, February 24, 2002 at 22:09:31 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour Hmmm... Let's recap: cp $1 $2 cvs rm -f $1 cvs add $2 cvs commit -m moved $1 to $2 $1 $2 Where is the *location of the RCS file* recorded in the comment? You don't need to know the location of the RCS files -- that's internal to CVS and not for human consumption. It's of no use in a client-server invocation in any case. Oh, I think I see. The wrapper would parse the output of the comment (hoping that it doesn't get confused with comments that merely /look/ like rename comments), and follow the chain of renames. This sounds slow since it'll require a CVS invocation for each rename. It's also a little brittle in that if there's a new CVS command, one would need to wrap that as well (unless you pass all commands to CVS and make it handle bad commands). You don't need to know it because of course the pathnames given in the parameters $1 and $2 will always have a fixed relationship to each other and that relationship is sufficient to transform either into the pathname necessary for use with 'cvs log' or 'cvs update -p', etc. no matter where the reader starts from (so long as they are within a working directory for the same module and so long as they know where they are with relation to the log they're currently reading). This is really very trivial pathname stuff -- I don't understand why you even think it's an issue. You're assuming no absolute paths are given to the command. Noel __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Greg A. Woods [EMAIL PROTECTED] wrote: You really need to learn more about how CVS works internally. If you had chosen CVS because RCS was insufficient for your needs then I think you would be happy not to have such a mapping layer. CVS handles renames by way of removing and adding files. No history is lost, but also no complications are introduced by such a mapping layer. What complications are you implying? Implementing a mapping layer in CVS will hurt CVS. It is impossible to implement such a mapping layer without destroying backwards compatability. Like I said before, one would be destroying forward compatibility, not backward compatibility. I see nothing wrong with doing this, since if you need to maintain forward compatibility, don't use the new feature (ie cvs mv). Noel __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Sunday, February 24, 2002 at 22:09:31 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour Hmmm... Let's recap: cp $1 $2 cvs rm -f $1 cvs add $2 cvs commit -m moved $1 to $2 $1 $2 Where is the *location of the RCS file* recorded in the comment? You don't need to know the location of the RCS files -- that's internal to CVS and not for human consumption. It's of no use in a client-server invocation in any case. You don't need to know it because of course the pathnames given in the parameters $1 and $2 will always have a fixed relationship to each other and that relationship is sufficient to transform either into the pathname necessary for use with 'cvs log' or 'cvs update -p', etc. no matter where the reader starts from (so long as they are within a working directory for the same module and so long as they know where they are with relation to the log they're currently reading). This is really very trivial pathname stuff -- I don't understand why you even think it's an issue. What you say is only true if both the source and destination of the rename are contained within the same module for the lifetime of the file, and that that module is the only one that contains them. But that is not the general case. When the module is not defined trivially, i.e. it uses aliases or inclusion, the relationship between the two files becomes variable. In the event that a file is moved into a shared module and at a later time the target file's history is needed (from within a module other than the original one), there's no record of its original module in the comment. This situation is complicated further in the event that the modules database is modified and the original directory is no longer included in the old module definition. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Tuesday, February 26, 2002 at 01:29:49 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour BTW, 'patch' is a _standard_ Unix tool. It's documented in The Single UNIX Specification, and it will be in IEEE Std. 1003.2b. Fine. So are cut and paste. You don't use them (preferring to use something else that better fits your need, see quote below), so why should my colleagues use patch if they prefer using something else that better fits their need? You really do know how to get off track and squirm out from under the pressure when you've been caught off-gaurd with a real answer to the original question you asked. So, if we take this squirming full circle then what better tools do you and your colleagues use to apply changes in the form of diff output to files? If you really can't figure out the difference between knowing which tool in the toolbox is best to use for a given situation, and not even knowing what tools are in the toolbox in the first place, then you really should think twice before perpetuating debates such as these with your ill-informed ideas. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Tuesday, February 26, 2002 at 00:27:36 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour Why bother with patch when merge is better? Or even better yet, cvs update? You haven't been paying attention, have you. The answer to your questions was what started this debate in the first place. Interesting, I just read the man page for patch again, and it doesn't mention diff3. According to this, all that patch does is it takes the difference between one file and another, applies the difference to a copy of the first file to produce a copy of the second file. And what can produce a difference between one file and another? Why 'diff3' can! Oh! Wow! What revalation! (obviously it does a wee bit more than that, but only slightly) This is a simple 2-way merge, which we all know is inferior to 3-way merges because they don't account for situations in which the delta is applied to something that isn't identical to the first file. Hmmm so you really don't understand what 'diff3' does, eh? RTFM my friend, and then play some games with it. Perhaps someday you'll see the light. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Tuesday, February 26, 2002 at 01:29:49 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour BTW, 'patch' is a _standard_ Unix tool. It's documented in The Single UNIX Specification, and it will be in IEEE Std. 1003.2b. Fine. So are cut and paste. You don't use them (preferring to use something else that better fits your need, see quote below), so why should my colleagues use patch if they prefer using something else that better fits their need? So, if we take this squirming full circle then what better tools do you and your colleagues use to apply changes in the form of diff output to files? We skirt the issue entirely and avoid passing diff output around. We keep complete copies of the files that concern us, and use a merge tool. If you really can't figure out the difference between knowing which tool in the toolbox is best to use for a given situation, and not even knowing what tools are in the toolbox in the first place, then you really should think twice before perpetuating debates such as these with your ill-informed ideas. We know which tool best fits our needs for a given situation, and very rarely is it named patch. Like you, we pick and choose the tools we need to get the job done and ignore the rest. It just so happens that our toolbox contains different stuff from yours. Our toolbox works just fine for us, so get over it. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Tuesday, February 26, 2002 at 10:27:23 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour inclusion, the relationship between the two files becomes variable. In the event that a file is moved into a shared module and at a later time the target file's history is needed (from within a module other than the original one), there's no record of its original module in the comment. But that is definitely not the general case. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Tuesday, February 26, 2002 at 16:19:11 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour --- Forwarded mail from [EMAIL PROTECTED] [ On Tuesday, February 26, 2002 at 10:27:23 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour inclusion, the relationship between the two files becomes variable. In the event that a file is moved into a shared module and at a later time the target file's history is needed (from within a module other than the original one), there's no record of its original module in the comment. But that is definitely not the general case. It may not be the absolute most common case (trivial module declarations are), but it falls well within the normal bounds of modules database usage. No, not even the normal bounds -- only the possible bounds. There have been many discussions, and there's even documentation in several places, telling all who'll read it that using non-trival modules declarations is like dancing with the devil -- you will encounter problems! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Greg A. Woods [EMAIL PROTECTED] wrote: You really do know how to get off track and squirm out from under the pressure when you've been caught off-gaurd with a real answer to the original question you asked. Actually, Paul's question, IIRC, was how many know and use these tools out of the toolsmiths on this list. From the responses, I'd say, not many. Out of the (I think) four responses, not more than half replied with knowing all those tools. Noel __ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Tuesday, February 26, 2002 at 19:05:04 (-0800), Noel Yap wrote: ] Subject: Re: CVS Update Behaviour --- Greg A. Woods [EMAIL PROTECTED] wrote: You really do know how to get off track and squirm out from under the pressure when you've been caught off-gaurd with a real answer to the original question you asked. Actually, Paul's question, IIRC, was how many know and use these tools out of the toolsmiths on this list. Well to start with his list of tools was almost totally irrelevant to the discussion at hand (perhaps his attempt to mis-direct the discussion onto some irrelevant side issue) From the responses, I'd say, not many. Out of the (I think) four responses, not more than half replied with knowing all those tools. ... and given the number of meaningful replies at all I'd say the results are as yet totally meaningless, at least statistically speaking. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Friday, February 22, 2002 at 20:57:01 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour --- Forwarded mail from [EMAIL PROTECTED] [ On Friday, February 22, 2002 at 13:25:37 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour And every time a merge is done from a branch where a rename was done on one of the branches. And what has been said about that for years now? DON'T DO THAT Yeah, right after it was said that such a capability is a requirement... Such merging is common in the maintenance phase of a product. Huh? What kind of idiocity is that? Since when are renames an absolute requirement of maintenance? Anyone silly enough to do a rename during maintenance and to do so only on the patch branch, is going to get what they deserve! (I.e. a whole lot of unnecessary confusion and a lot of extra manual work during merges! :-) Renames are not usually a requirement of maintenance, but they are a requirement of new development. Bug fixes are done during maintenance, and merged into new development. That means that bug fixes are merged into new development, often after prior new development involved renames. This mode of operation is common! Sometimes renames are done on a task branch and folded into the next release, and I've seen this more often than I care to remember on vendor branches. It's not a standard tool, so it falls well outside their experience. (Most are not even familiar with all of the standard Unix tools.) patch has been a standard tool in unix development for nearly two decades now. Prior to that the commonly used tool that can do the exact same job with only slightly less success and using the exact same tool to create the diff, was called 'ed'. It's been around for over three decades now. Time to crawl out from under your rock and get with the program Paul! Just because a tool is standard does not mean it's well-known or well-supported. 40% of the Unix platforms I use regularly (Solaris and NetBSD) don't even supply the tool, and I admit that this is a much lower number than I expected. (AIX, HP-UX, and MacOS X do supply it.) When's the last time anyone's used tsort(1), join(1) or fmt(1), or even cut(1), paste(1) or fold(1), and Greg's favorite ed(1), even on this list that's full of toolsmiths? ls, diff, ln, cc, ld, vi, more, make, dbx, nm, ar, tar, cp, chmod, ftp, cd, pwd, compress, sort, gzip (despite its non- standard status), telnet, xterm, id, mailx, echo, test, date, and perhaps a dozen or so other standard tools plus another dozen or so shop-specific tools make up the world as far as my developers are concerned. Virtually everything else to them is as obscure and unknown to them as the tools I listed in the first sentence of this paragraph. Because the developers are doing the merging and they don't know about patch, chances are they won't choose to use it. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
Hi Larry, It turns out that CVS already does what I wanted all along! If you don't checkout a complete directory CVS creates a Entries.Static file in the CVS directory. When you do an update it will then only update the existing files. Colm A Larry Jones wrote: Colm Murphy writes: What I would propose is the following update behaviour: (1) Update only the existing files in existing directories. You can achieve that by doing cvs update *. -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: CVS Update Behaviour
In article [EMAIL PROTECTED], Nagy Gabor wrote: On 02-Feb-22 14:14, Greg A. Woods wrote: No, you're full of crap too if you think that's a necessary feature. Frankly. Why does it hurt you that someone else needs something else from your favourite tool? I think renaming and moving files accross directories is nice to have. I don't think it is necessary, in a way that I can live without this feature. But then, there is a surprising lot that human beings can live without. You could wear a loincloth and live in a cave, hunting your dinner using sticks and stones, and not year for, nor even know, anything else. Since, therefore, civilization itself is not a necessary feature, it's pointless to squabble over whether directory versioning in a version control system is necessary. Progress is not created by necessity, but just by doing cool stuff for the hell of it, and for convenience and profit. And I still long for the mapping of entities to filenames. I don't any more. -- Meta-CVS: version control with directory structure versioning over top of CVS. http://users.footprints.net/~kaz/mcvs.html ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
In article [EMAIL PROTECTED], Paul Sander wrote: patch has been a standard tool in unix development for nearly two decades now. Prior to that the commonly used tool that can do the exact same job with only slightly less success and using the exact same tool to create the diff, was called 'ed'. It's been around for over three decades now. Time to crawl out from under your rock and get with the program Paul! Just because a tool is standard does not mean it's well-known or well-supported. 40% of the Unix platforms I use regularly (Solaris and NetBSD) don't even supply the tool, and I admit that this is a much lower number than I expected. (AIX, HP-UX, and MacOS X do supply it.) Free software development depends critically on patch. Just about anyone involved in it must know how to produce and apply patches. When's the last time anyone's used tsort(1), join(1) or fmt(1), or even cut(1), paste(1) or fold(1), and Greg's favorite ed(1), even on this list that's full of toolsmiths? I used fmt a second ago, because the machine I post from has a really bad vi clone that I haven't bother to replace. So to reformat a paragraph I use !}fmt. Sad! I used cut not too long ago. Let's see, tsort a few years ago, for something completely unrelated to sorting archive order for a braindead linker. I just needed to topologically sort some some strings for some reason. I *can* use ed, but haven't practiced in a few years. Never used paste or fold. I know what join is, and maybe played with it a decade ago. ls, diff, ln, cc, ld, vi, more, make, dbx, nm, ar, tar, cp, chmod, ftp, cd, pwd, compress, sort, gzip (despite its non standard status), telnet, xterm, id, mailx, echo, test, date, and perhaps a dozen or so other standard tools plus another dozen or so shop-specific tools make up the world as far as my developers are concerned. Virtually everything else to them is as obscure and unknown to them as the tools I listed in the first sentence of this paragraph. Because the developers are doing the merging and they don't know about patch, chances are they won't choose to use it. A programmer that doesn't know patch is quite likely ignorant of free software in general. This in turn suggests that the programmer, by choice, has seen very little code other than his or her own, and that of a few immediate colleagues. -- Meta-CVS: version control with directory structure versioning over top of CVS. http://users.footprints.net/~kaz/mcvs.html ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] In article [EMAIL PROTECTED], Paul Sander wrote: patch has been a standard tool in unix development for nearly two decades now. Prior to that the commonly used tool that can do the exact same job with only slightly less success and using the exact same tool to create the diff, was called 'ed'. It's been around for over three decades now. Time to crawl out from under your rock and get with the program Paul! Just because a tool is standard does not mean it's well-known or well-supported. 40% of the Unix platforms I use regularly (Solaris and NetBSD) don't even supply the tool, and I admit that this is a much lower number than I expected. (AIX, HP-UX, and MacOS X do supply it.) Free software development depends critically on patch. Just about anyone involved in it must know how to produce and apply patches. Most of the people I work with don't produce free software, or at least they don't collaborate in producing it. I do produce free software, and I still use patch only once in 2-3 years. The free software community remains a surprisingly small one, compared to the total size of the industry, and it's my job to support people who are not part of that small community. When's the last time anyone's used tsort(1), join(1) or fmt(1), or even cut(1), paste(1) or fold(1), and Greg's favorite ed(1), even on this list that's full of toolsmiths? I used fmt a second ago, because the machine I post from has a really bad vi clone that I haven't bother to replace. So to reformat a paragraph I use !}fmt. Sad! I used cut not too long ago. Let's see, tsort a few years ago, for something completely unrelated to sorting archive order for a braindead linker. I just needed to topologically sort some some strings for some reason. I *can* use ed, but haven't practiced in a few years. Never used paste or fold. I know what join is, and maybe played with it a decade ago. In other words, you don't use many of the standard tools. ls, diff, ln, cc, ld, vi, more, make, dbx, nm, ar, tar, cp, chmod, ftp, cd, pwd, compress, sort, gzip (despite its non standard status), telnet, xterm, id, mailx, echo, test, date, and perhaps a dozen or so other standard tools plus another dozen or so shop-specific tools make up the world as far as my developers are concerned. Virtually everything else to them is as obscure and unknown to them as the tools I listed in the first sentence of this paragraph. Because the developers are doing the merging and they don't know about patch, chances are they won't choose to use it. A programmer that doesn't know patch is quite likely ignorant of free software in general. This in turn suggests that the programmer, by choice, has seen very little code other than his or her own, and that of a few immediate colleagues. I would say that that pretty much describes most of the people I've ever worked with. They're very focussed on what they do very well and at the end of the day they'd rather spend time with their families than hack with the rest of us. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour Renames are not usually a requirement of maintenance, but they are a requirement of new development. Bug fixes are done during maintenance, and merged into new development. That means that bug fixes are merged into new development, often after prior new development involved renames. This mode of operation is common! Sometimes renames are done on a task branch and folded into the next release It is extremely rare for bug fix merges to work automatically with CVS commands alone, with or without any renames getting in the way. If the maintenance programmers don't understand explicitly what they're doing then they will not succeed. If you've seen such problems so often then you've been working with people who do not understand what they are doing, and that's very dangerous for the product they're working on. and I've seen this more often than I care to remember on vendor branches. huh? what do vendor branches have to do with this? If you don't understand that you have to manually move changes between files that have been renamed by the vendor then you should not be messing with such complicated things that you do not understand. When's the last time anyone's used tsort(1), join(1) or fmt(1), or even cut(1), paste(1) or fold(1), and Greg's favorite ed(1), even on this list that's full of toolsmiths? Hmmm... I don't use fmt or fold, or cut paste very often, but that's because I use better tools to do what they can do I certainly do know of their existance though, and what they could do if I needed them. If a developer doesn't read down to SEE ALSO section then they are not really a developer. RTFM means the WHOLE manual, not just the synopsis! Would you allow a dentist to work on your teeth if he or she didn't know of all the standard tools a dentist might need to do a good job fixing your teeth? Would you sit in the chair after you saw a lone pair of vice grips on the tray, even if it was a very nice shiny sterilized stainless steel pair? Get real Paul! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Sunday, February 24, 2002 at 20:13:51 (-0800), Noel Yap wrote: ] Subject: Re: CVS Update Behaviour --- Greg A. Woods [EMAIL PROTECTED] wrote: patch has been a standard tool in unix development for nearly two decades now. Prior to that the commonly used tool that can do the exact same job with only slightly less success and using the exact same tool to create the diff, was called 'ed'. It's been around for over three decades now. Time to crawl out from under your rock and get with the program Paul! Greg, your experience is not the norm. Most developers, possibly sadly, aren't familiar with the whole gamut of available commands. It damn well better be the norm -- it's no better or worse than anyone else's experience! Any so-called developer who is not familiar enough with the tools used daily to do his or her job is not really a developer. Some idiot might pay such a person to be a developer, but that doesn't make them a developer in the real world -- only in the imaginations of the employer and the employee. The tools I refer to are very plainly documented in the CVS manual and the CVS unix-style manual page. Even a simple skim through the manual page for GNU diff (the diff used with CVS, though unfortunately it's not shipped with CVS) will also reference the manual page for 'ed' and 'patch', and gives quite strong hints at how to use these tools to mechanically re-apply changes with them. Anyone claiming to be a developer but not able to figure this out on their own really needs to be smacked with something a lot harder than a clue-by-4! I'm certain even a non-developer can figure enough of this out to ask for help. I don't even have the time of day for any idiot who can neither figure this out nor ask for help. Furthermore, to do a proper merge, one needs three files. I think patch is incomplete since all the information between the ancestor revision and the current file is completely lost. You're on strange drugs again my friend. The patch input file will only be incomplete if you fail to generate it properly. One of the first lines in the output of man patch hints at this: patch - apply a diff file to an original Uh hug. Diff and diff3 produce diff files. Patch takes the output of diff _or_ diff3 as input. Since, when merging, one doesn't apply a diff file to _the original_, patch isn't really the ideal tool to do it. Well, first off, it seems you've got to learn a wee bit more about how 'diff' and 'patch' work conceptually before you'll realise that to an original does not mean what you think it means. Every newbie may suffer the same mis-interpretation, but I'm not sure that means the phrase is wrong in the context it is in. One could use diff3, but if that were true, why couldn't CVS do it itself? Huh? CVS does use diff3 to produce diff output. You can use diff3 manually too. It's terriblly easy to do. Most humans can easily manage up to seven items in their short-term memory -- diff3 only needs three (four if you count the command name itself). Do _you_ not know how this stuff all fits together yet? I thought you were worthy of being called a developer! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Update Behaviour
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] [ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour Renames are not usually a requirement of maintenance, but they are a requirement of new development. Bug fixes are done during maintenance, and merged into new development. That means that bug fixes It is extremely rare for bug fix merges to work automatically with CVS commands alone, with or without any renames getting in the way. It is? It is possible that we have different sorts of bugs than those you're familiar with, but we find that bug fixes often merge very nicely without manual handling. This is important; our business mandates that we maintain different branches for different customers. (We have few and large customers, compared to many other software houses.) Obviously, this will not work when files have been renamed, but in that case the changes between versions are likely to be so large that it really doesn't matter. In many cases, the bug has been removed in the redesign anyway. huh? what do vendor branches have to do with this? If you don't understand that you have to manually move changes between files that have been renamed by the vendor then you should not be messing with such complicated things that you do not understand. It seems to me that the question is not understanding, but whether it is desirable. It would be nice if CVS would track vendor renames, but it would have to be able to figure out vendor renames, and in any case the sources we track tend to be kept in CVS anyway, so the supplier is unlikely to rename things gratuitously. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
You're spreading F.U.D. and untruths again Paul. [ On Friday, February 22, 2002 at 20:51:55 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour There's just one little problem with this: cvs log only works when a file is in your sandbox. If it's been removed and committed, then you must do something like cvs rlog `cat CVS/Repository`/oldfile.c | less. That's not true. You are (still) using an old or broken or otherwise buggy version of CVS. But that only works if the file was renamed in the same directory, not if it was moved to another directory. This style of usage works just fine for me: cvs log ../old-dir-path/oldfile.c In this latter case, you need to know where in the repository the RCS file sits, and that info isn't usually available without some effort, particularly if the module isn't defined trivially in the modules database. Yes it is. It's in the commit message written automatically by something like my tiny simple little wrapper script. This exercise also doesn't consider the implications of doing the cvs add part in a sandbox that has been updated with a different branch than the original file. That's because doing such a stupid thing is outside the bounds of defined usage for CVS -- you really should only have one complete and coherent sandbox, all checked out on only one branch if you're using branches. Anything and everything else may lead to undefined behaviour. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Friday, February 22, 2002 at 20:57:01 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour --- Forwarded mail from [EMAIL PROTECTED] [ On Friday, February 22, 2002 at 13:25:37 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour And every time a merge is done from a branch where a rename was done on one of the branches. And what has been said about that for years now? DON'T DO THAT Yeah, right after it was said that such a capability is a requirement... Such merging is common in the maintenance phase of a product. Huh? What kind of idiocity is that? Since when are renames an absolute requirement of maintenance? Anyone silly enough to do a rename during maintenance and to do so only on the patch branch, is going to get what they deserve! (I.e. a whole lot of unnecessary confusion and a lot of extra manual work during merges! :-) Only if the developers know about it, and how use it. Yup, most developers I know do pick up wrenches to hammer in screws too... Sigh. When will you and they ever learn? It's not a standard tool, so it falls well outside their experience. (Most are not even familiar with all of the standard Unix tools.) patch has been a standard tool in unix development for nearly two decades now. Prior to that the commonly used tool that can do the exact same job with only slightly less success and using the exact same tool to create the diff, was called 'ed'. It's been around for over three decades now. Time to crawl out from under your rock and get with the program Paul! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Saturday, February 23, 2002 at 06:37:35 (-0800), Noel Yap wrote: ] Subject: Re: CVS Update Behaviour Because the tool is broken under such circumstances. It's broken because it claims to be concurrent, but under such circumstances, it's not. Huh? What can concurrent editing of the same file on the same branch possibly ever have to do with renaming a file on one branch but not on another? You've really lost it now Noel. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
I really really really really wish you'd learn to use a proper mail reader that can deal with text and not mangle it beyond reconition! You haven't been at all successful at avoiding double-posting either. [ On Saturday, February 23, 2002 at 06:00:52 (-0800), Noel Yap wrote: ] Subject: Re: CVS Update Behaviour --- Greg A. Woods [EMAIL PROTECTED] wrote: It seems perfectly simple and very quick when I do it. Perhaps you should try it: cvs log newfile.c | less [[ read along until you get to the end and see: - moved oldfile.c to newfile.c]] cvs log oldfile.c | less [[ and so on ]] 1. This doesn't work in the general case (eg when resurrections occur). Huh? Sure it does -- though of course you need to modify the algorithm above to get rid of the to the end part -- but then humans are usually pretty good at figuring out such implications on their own. 2. This is hardly transparent to the user. It's bloody well not supposed to be transparent! You _WANT_ them to see the rename and understand its implications! Maybe someone with difficulty typing commands would find this difficult because of the extra typing, but they would presumably find using any part of the command-line interface to be similarly difficult and should probably be using a mouse-driven front-end or some such. No, the difficult part is parsing the log output to find the move comments (assuming the comments are correct to begin with). The comments are correct because you've required that your developers use a front-end or wrapper. Right!?!?!?! Humans are incredibly good at parsing written words. However even computers can discern such patterns with ease. Because they're too simple and too lame to ever worry about remembering! And it's much simpler to argue continuously about it? it's no harder, and a whole lot more fun! Yup, that's pretty much it. It sure is easy isn't it! You need some more mechanism around it if you want to use it as a general wrapper (i.e. to enforce its usage), and of course there are the other bits that should be self obvious if you want log and diff and such to work across renames. Since anyone can always call CVS directly, how can you possibly enforce its usage (other than through policies)? You can make it harder for anyone to use an un-modified version of CVS, but really policies are all that's necessary. If you need more control than this then your project management is already too far gone to have much hope for success at anything. Whereas if CVS directly supported this, one wouldn't have to add this functionality to each wrapper out there. CVS simply cannot ever support the kind of renames some very few of you continually whinning complainers seem to wish to have without introducing fundamentally backwards incompatible changes to the repository format. So, either start your own new project that has no ties to past repositories, or quit your bloody whining! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Greg A. Woods [EMAIL PROTECTED] wrote: patch has been a standard tool in unix development for nearly two decades now. Prior to that the commonly used tool that can do the exact same job with only slightly less success and using the exact same tool to create the diff, was called 'ed'. It's been around for over three decades now. Time to crawl out from under your rock and get with the program Paul! Greg, your experience is not the norm. Most developers, possibly sadly, aren't familiar with the whole gamut of available commands. Furthermore, to do a proper merge, one needs three files. I think patch is incomplete since all the information between the ancestor revision and the current file is completely lost. One of the first lines in the output of man patch hints at this: patch - apply a diff file to an original Since, when merging, one doesn't apply a diff file to _the original_, patch isn't really the ideal tool to do it. One could use diff3, but if that were true, why couldn't CVS do it itself? Noel Noel __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] You're spreading F.U.D. and untruths again Paul. Not with the stock version of CVS that I'm using. Larry Jones has already set me straight with regard to cvs log working properly in the presence of a file that's been removed to the Attic in the current release. [ On Friday, February 22, 2002 at 20:51:55 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour In this latter case, you need to know where in the repository the RCS file sits, and that info isn't usually available without some effort, particularly if the module isn't defined trivially in the modules database. Yes it is. It's in the commit message written automatically by something like my tiny simple little wrapper script. Hmmm... Let's recap: cp $1 $2 cvs rm -f $1 cvs add $2 cvs commit -m moved $1 to $2 $1 $2 Where is the *location of the RCS file* recorded in the comment? Sure, the wrapper could read the CVS meta-data, but that's proprietary to CVS and therefore not guaranteed to remain compatible in future releases. This exercise also doesn't consider the implications of doing the cvs add part in a sandbox that has been updated with a different branch than the original file. That's because doing such a stupid thing is outside the bounds of defined usage for CVS -- you really should only have one complete and coherent sandbox, all checked out on only one branch if you're using branches. Anything and everything else may lead to undefined behaviour. Yeah, well, users can be pretty ingenius when it comes to stuff like this. The wrapper should at least look at the sticky tags of the workspaces to make sure they're not doing something stupid. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
On 02-Feb-22 18:31, Greg A. Woods wrote: And what has been said about that for years now? DON'T DO THAT It's time to give that a second thought, IMHO. This involves several files every time a patch goes out, if the project was reorganized since the code diverged. This phonomenon is much more common than you think. Maybe because of accidents, but that's something which is correctable. Last release one output file was created by a simple C++ source. In the current release I also have to put some data from ORACLE into the output. I renamed the file from *.cpp to *.pc so that the make rules work OK. So far I didn't have to merge a change. Maybe the last release was perfect and I will never have. But it was not an accident. OK, I could create a new .pc to store functions that the .cpp could call, but this is just a way around the problem. You don't want to admit that the problem does exist. Gee ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
On 02-Feb-22 14:14, Greg A. Woods wrote: No, you're full of crap too if you think that's a necessary feature. Frankly. Why does it hurt you that someone else needs something else from your favourite tool? I think renaming and moving files accross directories is nice to have. I don't think it is necessary, in a way that I can live without this feature. But if I think that this would make my life easier, don't try to tell me, I shouldn't _think_ that. When I discovered cvs did not know this, I was puzzled, and sad. And used and liked cvs ever since. During these years I've used other tools, which had this feature. I noted, that it was good. But if I can choose, I choose cvs. And I still long for the mapping of entities to filenames. What I would like to see, is a kind of Inode way of storing things in the repository. Multiple names of the same entity, renames, anything. And one representation Lastly: If there is something that doesn't hurt you, (you can cat a file to another name and rm the old one, don't have to mv, so you can do it as you always did) but others would like to have that particular feature, why object? Why do you want to judge if it is rightfully needed by others? You don't need this. cvs doesn't do this at the moment. Why is that a problem, if we are talking about enhancing cvs so that in the future it will suit the needs of more people? Maybe the current repository structure can't hold this information. I don't know, as I'm only a user of cvs. But I don't understand why people seem to go crazy over the mention of this wishlist item. First off tell me how often you've actually had to do this operation in relation to other operations. I'd say one time is enough. In the current project I'm working on, there were renaming of files, and branches and bugfixes in previous releases. Yes, I can merge with typing. But I wouldn't mind if all I have to do was the same as with files with the old name. Gee ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Greg A. Woods [EMAIL PROTECTED] wrote: Perhaps what I can now do intuitively is hard for someone else, but if I learned to do it intuitively then pretty much anyone can learn it too. I'm no superman and I don't believe I have a photographic memory or anything fancy like that either. You need to get out and work with a broader set of people. From my experience, script-proficient developers are a rarity. Taking into account the reality, you and probably most on this list are supermen. Perhaps someone who doesn't understand the basics of what's going on with version control might have more trouble, but they're basically lost on even the most simple commands until they get some fundamental understanding anyway. Once they get the basics under control then tracking history across renames is only a tiny step, not anything difficult! You're defining version control to be CVS, again. You need to remember that there are tools that version control renames transparently to the user. But I understand how you can forget such a thing given that you don't use such tools. It seems perfectly simple and very quick when I do it. Perhaps you should try it: cvs log newfile.c | less [[ read along until you get to the end and see: - moved oldfile.c to newfile.c]] cvs log oldfile.c | less [[ and so on ]] 1. This doesn't work in the general case (eg when resurrections occur). 2. This is hardly transparent to the user. Maybe someone with difficulty typing commands would find this difficult because of the extra typing, but they would presumably find using any part of the command-line interface to be similarly difficult and should probably be using a mouse-driven front-end or some such. No, the difficult part is parsing the log output to find the move comments (assuming the comments are correct to begin with). So automate the process with a wrapper that doesn't make mistakes!! Said wrapper is already quoted below! And be sure to break the CVS model by serializing development while you're at it. If being able to deal transparently with file renames and moves is important to one, then CVS is not the proper tool. Well we do agree on that for sure -- but I assert it's never going to be a terribly important requirement in any usage domain where CVS is otherwise the proper tool. Good, so we're in agreement, CVS isn't ideal under refactoring or when using XP. That's actually kind of sad. Why don't you put the script(s) in the contrib directory, and point people at it when the topic comes up, rather than expending the effort arguing and re-writing the script? Because they're too simple and too lame to ever worry about remembering! And it's much simpler to argue continuously about it? Yup, that's pretty much it. It sure is easy isn't it! You need some more mechanism around it if you want to use it as a general wrapper (i.e. to enforce its usage), and of course there are the other bits that should be self obvious if you want log and diff and such to work across renames. Since anyone can always call CVS directly, how can you possibly enforce its usage (other than through policies)? Such a feature could trivially be built into the many front-ends too (which are usually literally wrappers), such as PCL-CVS (which is the one I use), or WinCVS, etc. What if some valid comments happen to have the move comments in them and the file wasn't really moved? Using comments for this is a hack at best. I've never actually written a script to do it because it's brain-dead easy and obvious how to do it manually, and like I said I can only remember having to do a diff manually across a rename once in 8 yrs! If it's so obvious, why on Earth do you think this subject comes up so often? Obviously, it's not obvious. I did think briefly of writing rename support for PCL-CVS, but it's just too infrequently used to be worth the effort. Whereas if CVS directly supported this, one wouldn't have to add this functionality to each wrapper out there. If/when someone goes to the effort of produceing working code regardless of how needed it is then perhaps it'll be added to the appropriate public shared version of wherever it best fits (eg. a script in contrib or a new lisp function in PCL-CVS, or whatever). Until that time the manual way is trivial, and quick, and it works 100%. No, it doesn't. It's not robust. A robust way wouldn't use comments, but use something completely internal to CVS (eg filename mapping). Noel __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Greg A. Woods [EMAIL PROTECTED] wrote: [ On Friday, February 22, 2002 at 13:25:37 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour And every time a merge is done from a branch where a rename was done on one of the branches. And what has been said about that for years now? DON'T DO THAT Because the tool is broken under such circumstances. It's broken because it claims to be concurrent, but under such circumstances, it's not. Not renaming files is a fine workaround for lacking the ability to rename files, if you can live with it. You can obviously live with it, but some of us cannot. Who said you can't rename files? You just have to plan for it. And serialize development while you're doing it. Noel __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
Paul Sander writes: There's just one little problem with this: cvs log only works when a file is in your sandbox. If it's been removed and committed, then you must do something like cvs rlog `cat CVS/Repository`/oldfile.c | less. No, cvs log works just fine on a removed file: jones:/tmp/CVSROOT $ ls CVS config loginfo taginfo checkoutlistcvswrappers modules verifymsg commitinfo editinforcsinfo jones:/tmp/CVSROOT $ cvs log notify RCS file: /tmp/cvstest/CVSROOT/Attic/notify,v Working file: notify head: 1.2 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 2; selected revisions: 2 description: revision 1.2 date: 2002/02/23 21:10:37; author: scjones; state: dead; lines: +0 -0 . revision 1.1 date: 2002/02/23 19:56:14; author: scjones; state: Exp; initial checkin = -Larry Jones I just can't identify with that kind of work ethic. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] Paul Sander writes: There's just one little problem with this: cvs log only works when a file is in your sandbox. If it's been removed and committed, then you must do something like cvs rlog `cat CVS/Repository`/oldfile.c | less. No, cvs log works just fine on a removed file: Oh, cool! Time to upgrade again... --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, February 21, 2002 at 18:03:20 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour That last paragraph is utter crap. Without having the entire history of a file's lifetime in one container, it's much much harder to track changes that are made before the last reorg. No, you're full crap, to be blunt about it. It's hardly even noticably more difficult to track the history across multiple files. You've been harping on this subject for literally years yet you've never contributed one line of code to make it easier and I'll bet you're so scared of this particular way of using CVS that you don't even try to do it yourself so how the hell would you know how hard it is to do!?!?!?!?!? Quit being an idiot Paul and either shut up or talk only about the things you actually have real live current experience with. I've done it the CVS way, actually I've done it in several of the CVS ways as documented in the manual. And I have modified CVS to try to make one or two of them easier. It can't be done with sufficient robustness to be worthwhile to submit to Larry and company, at least not without making incompatible changes to the format of the repository. And that's the way it sits as long as CVS uses the filesystem to map the locations of revision containers to sandboxes. I've also used systems do maintain a single revision history of a file throughout its lifetime. They are way more usable than CVS under these conditions, and some of them support concurrent development. The mapping can be done with text files (transparently to the user as an implementation detail), and the merge algorithms are virtually identical to what CVS already has built-in. All that the mappings do is add a level of indirection. There are secondary issues that can be complex, such as how one efficiently locks the revision containers during commits. But that's only an issue if CVS is used in local mode; the client/server modes can funnel the locking in such a way that the necessary coordination can be implemented well. This system would be more scalable if there were a way to permit concurrent modifications to the revision containers on different branches, but that's a lesser requirement than just getting the mapping at all. Rather than argue for the sake of arguing, I suggest that you try a system that has such a mechanism. Apply it to a non-trivial project, and try making fundamental changes to the layout of the sources. A Unix kernel with its drivers might be a good sample. Then try merging changes across branches. Because CVS doesn't have this feature, its users become accustomed to working around its absence. And they don't recognize the value of the feature until they've actually tried it in a real world situation using a different system. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
On Thu, 2002-02-21 at 21:03, Paul Sander wrote: --- Forwarded mail from [EMAIL PROTECTED] [ On , February 21, 2002 at 18:55:21 (-0500), Arcin Bozkurt - Archie wrote: ] Subject: Re: CVS Update Behaviour On Thu, 2002-02-21 at 17:45, Greg A. Woods wrote: Don't get stuck on this idea of trying to keep track of everything back to the beginning of time with one RCS file. So, you don't believe that history of those files are that important. Of course it's important -- it's your record of what happened to that code through its lifetime. It can tell you how bugs were fixed in the past, and how new bugs were introduced, and all kinds of management level information such as how many lines of code changed, who changed them, etc., etc., etc. It just doesn't have to be all in the same RCS file. The idea that it should is a very dangerous fallacy, esp. w.r.t. to CVS. That last paragraph is utter crap. Without having the entire history of a file's lifetime in one container, it's much much harder to track changes that are made before the last reorg. And it's especially difficult to track migrations through the reorg with respect to branches. For example, it's much harder to migrate bug fixes from old releases to new development if the new stuff involves renaming files. In the problem I am facing, we are not, at the moment, thinking of assigning new purposes to existing files and we are not planning any renamings... And going the other way, suppose a rename was done and a new file takes the place of the old one in the filesystem. Now you have a dangerous situation in which a single RCS files contains partial version histories of multiple files. It's dangerous because it opens up the possibility of someone merging inappropriate changes from one branch to another, from one file to another. A question on merge behaviour of cvs: Will CVS be able to follow a file disappearing in one module, appearing in another one? I would say no. And therefore a merge would not be able to propogate bugfixes on that file even though the file is not deleted, and resurrected for another, etc. Am I right? Here is an illustration: [... : illustration understood and taken out for clarity ] The fact that CVS doesn't map RCS files uniquely to sources in the context of reorganizations doesn't make the requirement to do so a fallacy. It makes CVS broken. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
(I should know better than to get into this...) On Fri, Feb 22, 2002 at 01:16:35AM -0500, Greg A. Woods wrote: It's hardly even noticably more difficult to track the history across multiple files. Greg, *that* statement is complete and utter crap. Or, please post the single *cvs* command that will display the full history (equivalent of 'cvs log') of an entity *accross* renames/moves. (I use the word entity because file allows an easy out: If you rename it, it's not the same file.) Please post the appropriate *cvs* command that will merge a one-line non-conflicting change in a branched file into the version on the trunk that has been renamed. Yes, I can write scripts and add-ons to deal with these situations. Many of us have done so. But the whole rename/move issue with CVS *is* a weakness. The fact that it can't be corrected within the limitations of CVS's current design/implementation is doesn't change the fact that it's a weakness. Now, I *like* CVS. I find that it meets the needs of our small development team, and the cost is certainly right (for our situation and uses, the admin cost (counted in my time, which I, at least, think has some value) is pretty small). But it *does* have some weaknesses, and those weaknesses have influenced our processes, just like the strengths and weaknesses of any tool influence how you use it. We know the limitations and work around them. But denying the limitation exists is silly. Steve Quit being an idiot Paul and either shut up or talk only about the things you actually have real live current experience with. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- I [..] am rarely happier then when spending an entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand. Ten seconds, I tell myself, is ten seconds. Time is valuable and ten seconds' worth of it is well worth the investment of a day's happy activity working out a way to save it. -- Douglas Adams, Last Chance to See ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Friday, February 22, 2002 at 12:18:37 (-0600), Steve Greenland wrote: ] Subject: Re: CVS Update Behaviour (I should know better than to get into this...) Yes, you really should! On Fri, Feb 22, 2002 at 01:16:35AM -0500, Greg A. Woods wrote: It's hardly even noticably more difficult to track the history across multiple files. Greg, *that* statement is complete and utter crap. Or, please post the single *cvs* command that will display the full history (equivalent of 'cvs log') of an entity *accross* renames/moves. No, you're full of crap too if you think that's a necessary feature. First off tell me how often you've actually had to do this operation in relation to other operations. There are probably as many or more functions that have do be done with CVS on a regular basis that require more than one command (or more than one click of the mouse for those of us who are most lazy and like to use a MUI or GUI) than can be done with one simple command. You should all be damn happy that CVS does the few things it can do. Would you rather repeat an RCS command for every file, or even just every directory for all your projects? If you're so damn worried about making it one simple command for your loser users then write damn wrapper and shut up. If you think the world should be able to do such things with one command then post your friggin wrapper. If you're too damn lazy to figure out how to do this then please ask politely for suggestions instead of spouting more whining useless BS. If you really think you know better how to do this then demonstrate your mastery with some working code! I've never heard so much BS about this subject, even after all these years of discussion about it, and yet I think I'm the only one to have actually done something about it _and_ shared my efforts! I've posted the basic starter wrapper I wrote to do this several times. In fact I wrote the damn wrapper separately each time. Any programmer with any clue about what's going on could easily extend my wrappers to do more complex tasks such as diffs and such, even if they didn't know the shell language before they started. Not that I've ever used my wrapper in production -- I've just demonstrated with working code that something productive can be done without whining about it so much! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
[ On Friday, February 22, 2002 at 01:48:50 (-0800), Paul Sander wrote: ] Subject: Re: CVS Update Behaviour I've done it the CVS way, actually I've done it in several of the CVS ways as documented in the manual. Only one of the ways documented in the manual even comes close to being the one correct way to do file renames. The other two ways have fatal flaws in a number of situations. I've posted updates to the manual which correct the documentation. Rather than argue for the sake of arguing, I suggest that you try a system that has such a mechanism. Apply it to a non-trivial project, and try making fundamental changes to the layout of the sources. A Unix kernel with its drivers might be a good sample. Then try merging changes across branches. I don't need to use any such over-burdened fancy system. I'm extremely happy with the way things work now in CVS -- there's more than adequate support for tracking renames across history, at least form the point of view of anyone actually needing the revision history and commit logs and not just arguing about a mythical need. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] On Thu, 2002-02-21 at 21:03, Paul Sander wrote: --- Forwarded mail from [EMAIL PROTECTED] [ On , February 21, 2002 at 18:55:21 (-0500), Arcin Bozkurt - Archie wrote: ] Subject: Re: CVS Update Behaviour And going the other way, suppose a rename was done and a new file takes the place of the old one in the filesystem. Now you have a dangerous situation in which a single RCS files contains partial version histories of multiple files. It's dangerous because it opens up the possibility of someone merging inappropriate changes from one branch to another, from one file to another. A question on merge behaviour of cvs: Will CVS be able to follow a file disappearing in one module, appearing in another one? I would say no. And therefore a merge would not be able to propogate bugfixes on that file even though the file is not deleted, and resurrected for another, etc. Am I right? You are correct. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Forwarded mail from [EMAIL PROTECTED] [ On Friday, February 22, 2002 at 12:18:37 (-0600), Steve Greenland wrote: ] Subject: Re: CVS Update Behaviour On Fri, Feb 22, 2002 at 01:16:35AM -0500, Greg A. Woods wrote: It's hardly even noticably more difficult to track the history across multiple files. Greg, *that* statement is complete and utter crap. Or, please post the single *cvs* command that will display the full history (equivalent of 'cvs log') of an entity *accross* renames/moves. No, you're full of crap too if you think that's a necessary feature. First off tell me how often you've actually had to do this operation in relation to other operations. I don't know about anyone else, but I use cvs log every time I do a cvs update to read other people's thoughts about the changes they've made to the code I'm about modify. If just one of those files has been renamed in its past, then I want cvs log to show the file's entire history, before and after the rename (and indeed before and after *every* rename in its past). --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
--- Greg A. Woods [EMAIL PROTECTED] wrote: I don't need to use any such over-burdened fancy system. I'm extremely happy with the way things work now in CVS -- there's more than adequate support for tracking renames across history, at least form the point of view of anyone actually needing the revision history and commit logs and not just arguing about a mythical need. I think anyone who has ever used such a system would disagree that such a need is mythical. Noel __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Update Behaviour
On Fri, Feb 22, 2002 at 02:14:21PM -0500, Greg A. Woods wrote: [ On Friday, February 22, 2002 at 12:18:37 (-0600), Steve Greenland wrote: ] On Fri, Feb 22, 2002 at 01:16:35AM -0500, Greg A. Woods wrote: It's hardly even noticably more difficult to track the history across multiple files. Greg, *that* statement is complete and utter crap. Or, please post the single *cvs* command that will display the full history (equivalent of 'cvs log') of an entity *accross* renames/moves. No, you're full of crap too if you think that's a necessary feature. You've failed to read what I wrote. I didn't claim it was necessary. I didn't claim it was common. I, in fact, wrote that I was generally satisfied with CVS. What I *wrote* was *your* claime that tracking history across renames was an effort that was hardly even noticably more difficult was crap. Since I can read the history of a single file (non-renamed) with one cvs command, I wanted to know how to do it when the file (entity, if you prefer) *had* been renamed, or moved to another directory. Reading the change log of the current file to (hopefully) find the comment about what the name of the file *used* to be and then reading its changelog, etc. etc. is *not* hardly more difficult. The only place the rename info is stored is in the changelog, and if the person who made the change didn't get the right comment in there, it's lost. Should the comment be there? Of course. But people make mistakes. If being able to deal transparently with file renames and moves is important to one, then CVS is not the proper tool. If you're so damn worried about making it one simple command for your loser users then write damn wrapper and shut up. My users are not losers. I'm not even particulary worried about it. When we need to do it, we know how. I've never heard so much BS about this subject, even after all these years of discussion about it, and yet I think I'm the only one to have actually done something about it _and_ shared my efforts! I've posted the basic starter wrapper I wrote to do this several times. In fact I wrote the damn wrapper separately each time. That's actually kind of sad. Why don't you put the script(s) in the contrib directory, and point people at it when the topic comes up, rather than expending the effort arguing and re-writing the script? Hmmm, searching in groups.google.com, the only thing I could find is cp $1 $2 cvs rm -f $1 cvs add $2 cvs commit -m moved $1 to $2 $1 $2 from January 2000. If that's the script you rewrite every time, well, yeah, that's easy. I was hoping that you meant you'd written scripts for logging, and/or diffing and merging a branch when files have been moved/renamed. If you have, they should go in contrib. If not, the fact that no one has done them and posted them might, just might, indicate that they aren't as trivial as you claim. In the meantime, I'll go on using CVS because it does the things I need it to do. But there are some things it doesn't do well, and if one or more of them is important to a particular user, then the only honest, fair thing to do is steer them away from CVS. Steve -- I [..] am rarely happier then when spending an entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand. Ten seconds, I tell myself, is ten seconds. Time is valuable and ten seconds' worth of it is well worth the investment of a day's happy activity working out a way to save it. -- Douglas Adams, Last Chance to See ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
