CVS for rolling up?
Hi, the project I'm working in is thinking of moving to CVS. Currently we use SCCS - this was fine in the past, where we only worked on the latest version of our code. Now however, we have three versions. The first two versions are existing releases that are being maintained - the latest version is our current development. At some point then, the changes we make to our maintenance code will need rolled up into our current development. Is CVS the correct CM tool for doing this? I figured that by using the CVS merge command, the maintenance code changes could be easily rolled up into out current development. Does this seem sensible? Thanks for your time! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, October 10, 2001 at 14:40:11 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In one method, you lose the ability to get a file's entire revision history in one place (i.e. you must track down its old location(s) and fetch additional history from there). That's not a loss, nothing is lost -- that a stupid illogical complaint. And not only do you lose the ability to get a file's entire version history with a single cvs log, you also have added to a file's revision history all of the unwanted stuff from a previous incarnation that was renamed away. Defending the ambiguity of the histories of logically different files that happen to share a path at one time or another, and the fragmentation of a file's entire version history is nonsensical. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On , October 10, 2001 at 17:31:23 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] if you rename FOO to BAR the right way, i.e., $ mv FOO BAR $ cvs rm FOO $ cvs add BAR $ cvs ci BAR then you lose in many ways: No, you lose absolutely nothing -- in fact you _gain_ the information about the rename! This is only true if the user performing the steps above remembers to include a comment. The other thing is that because the rename isn't atomic, it can be only partially completed and cause problems for other developers caught up in the race condition. A usable rename would have the following user model and store the fact of the rename automatically: cvs mv FOO BAR cvs ci BAR The mv would move the working copy and update the CVS sandbox state as needed, ideally recording the fact of the move there to be stored at commit time. It would also have to be robust enough to be repeatable (i.e. cvs mv FOO BAR; cvs mv BAR BAZ; cvs commit BAZ) and reversible (i.e. cvs mv FOO BAR; cvs mv BAR FOO; cvs commit FOO) before the commit. The commit would (in a single transaction) deaden the appropriate version of FOO, create BAR (or resurrect it), create the appropriate tags (if the sandbox is on a branch), and commit local changes. But again, there are the fragmented history and ambiguous history problems. * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. It's totally logical if BAR and FOO are the same file, BAR having been renamed to FOO. Remember, the version histories of BAR and FOO are only fragments of the file's entire version history. * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. Not with the cvs diff command, it isn't (assuming BAR was renamed to FOO). You must have both files checked out somewhere (and one usually isn't) before the standard diff program will work. -- etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) It's trivial to undo too -- the same way you undo any commit. The first point was: etc - CVS does not know that FOO is the old name for BAR. That's the important part. Fragmented version histories are a royal pain. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
User Password to check out cvs tree
Dear all, maybe I am blind but I can neither find the user nor the password I need to submit when login into: cvs -d :pserver:[EMAIL PROTECTED]:/cvs login If someone please could tell me the username and the password just to download the latest code? Thanks in advance, -- Lukas RufSwiss Federal Institute of Technology Office: ETZ-G61.2 Computer Engineering and Phone: +41/1/632 7312Networks Laboratory (TIK) Fax: +41/1/632 1035 ETH Zentrum PGP 2.6: ID D20BA2ED;Gloriastr. 35 Fingerprint 6323 B9BC 9C8E 6563 B477 BADD FEA6 E6B7CH-8092 Zurich ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Assertion while importing Linux 2.4.12
Dear all, while I tried to check in Linux 2.4.12 I got the following errors: N linux/CVSROOT/checkoutlist cvs: import.c:577: process_import_file: Assertion `entdata-options[0] == '-' entdata-options[1] == 'k'' failed. cvs [server aborted]: received abort signal I launched the cvs import on linux into a freshly set up CVS Repository. Any hints? Lukas -- Lukas RufSwiss Federal Institute of Technology Office: ETZ-G61.2 Computer Engineering and Phone: +41/1/632 7312Networks Laboratory (TIK) Fax: +41/1/632 1035 ETH Zentrum PGP 2.6: ID D20BA2ED;Gloriastr. 35 Fingerprint 6323 B9BC 9C8E 6563 B477 BADD FEA6 E6B7CH-8092 Zurich ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Web interfaces that supports the CVSROOT/modules
http://www.sourceforge.com/projects/cvsbrowser/ It is in beta, and I haven't had time to work on it in a few months, but development is picking up again. It parses the modules file and builds the display based on that, including support for nested modules (module), including only specific files in a module, alias modules, and excluding specific directories from a module. It is incomplete. You can currently traverse down to the file you want, but very little of the file operations have been completed to date. It is written in PHP. If you or anyone else has interest let me know and I'll bump it up on my priority list a couple notches. -- David F. Rich Wittmer wrote: I have a developer that is interested in a web interfaces that supports the CVSROOT/modules file to display the directory representation rather than the actual set of directories. Does anyone know of a interface of this nature? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
SQL shema
hi, I was wondering how u people are working with SQL-shema changes... say I have it under CVS control... How u automate adding/removing tables and fields, and as special case populating some of the tables...!! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS + SSH under Unix and automatically use private keys
Matt McClure wrote: On Tue Oct 09 2001, 13:31, Paul Michali [EMAIL PROTECTED] wrote: However, when I run cvs (command line) from a Unix client, with CVS_RSH set to SSH, it prompts me for my passphrase. Is there a way to get around this so that it just uses the private key and continues without prompting? This is really a question about ssh rather than cvs. Can you ssh from your machine to the server without using a password? A while back, I was able to ssh to another system on our net and it would only ask for my password. Now, it asks for the passphrase. I have recently created a key pair as part of the setup for WinCVS. It looks like I'll need to read up on the SSH docs to understand the ways to set this up. Ideally, I want the security of not sending passwords in clear text, like rsh does I guess, and I don't want to have to type in my pass phrase for each and every CVS command as it is a pain. David Hoover wrote: Or better yet, use ssh-agent. I'll check into that, it looks like it might be what I want to do. Thanks for the responses, I think I know where I need to look (and what I need to learn more about). PCM (Paul Michali) Carrier Voice Gateway Business Unit (CVGBU) Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Phone : (800) 572-6771 x 45817 (978) 244-5817 [direct] Paging: (800) 365-4578 [voice] [EMAIL PROTECTED] [email page] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SQL shema
hi, I was wondering how u people are working with SQL-shema changes... say I have it under CVS control... How u automate adding/removing tables and fields, and as special case populating some of the tables...!! CVS is not a build tool. To make sure that all the schemata and the application code (all of it) is consistent, you really have to have regression tests that exercise all of the table definitions. Only when all regression tests pass would you commit *.sql and application code to CVS (or rather, it would be commited earlier, but given it some significant tag or branch when everything flies again). This is not trivial, especially if people have to hand tweak the schema's inside the databases (which is not uncommon). If they do so, dump the schema from the database, can commit it. I would suggest using a layer of view definitions (to be used by the application code) can help insulate you from schema churn. A final scenario is that the tables definitions are embedded in the applications (e.g. if you have some object layer). In this case, *.sql is a derivation, hence should not be stored under CVS. -- The mail transport agent is not liable for any coffee stains in this message - Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
view differences in the CvsIn
Hi, I need some help with the CvsIn (add-on of the WinCvs to the Visual C++). I'm using the Beyond Compare to view the differences between two versions of a file. I've setup the Beyond Compare as an external diff program both in the WinCvs preferences and in the CvsIn. When I've pressed the diff button in the WinCvs it opens a dialog in which I can choose the version that I want to compare my file with. Doing the same thing in the through the Visual C++ with the tool bar of the CvsIn won't open the dialog box, instead it opens directly the external diff program. When I open the Beyond Compare through the WinCvs, after I choose to compare with the same remote version in the mentioned dialog box, it opens my file and the recent version of the file from the repository (which now is in a temporary directory). When I open the Beyond Compare through the Visual C++, it opens my file (which I've changed earlier) and the version that I have in my local workspace (which isn't the latest version in the repository). Why is that happening? Is there something I can to force the CvsIn work exactly like the WinCvs in this case? Any help would be appreciated! Hila. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
commit as root.
Hello everybody! I have a question. I need to work as root in a specific project. But, when I try to commit the modified files, I get a message telling that commit cannot be done as root. I am using the motor IDE. Does anybody know a way to commit the changes as root? Thanks very much. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
(WARNING: Viagra may be dangerous to drywall for those who do not suffer from impotency)
Pill store, get cheap easy perscriptions! VIAGRA HERE! http://affiliates.pillstore.com/store/golduc (WARNING: Viagra may be dangerous to drywall for those who do not suffer from impotency) BET YOUR FAVORITE TEAM HERE! http://www.sbgglobal.com/index.htm?0001@gold Do you believe in YOUR TEAM? This company WILL PAY if you WIN! If you consider this mail to be 'SPAM' Click Reply and put the word 'REMOVE' in the subject line, YOU WILL BE removed if you do so. Thanx ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
notify
Please tell me how I configure the notify CVS admin file along with any other files to send e-mail to myself or other development personnel in the event of changing and commiting source files. Jeff ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 01:03:59 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 10, 2001 at 17:31:23 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. why? this is the same file. to use a very specific example: CLISP (http://clisp.cons.org) used lsp extension for CL files but switched to lisp a couple of years ago. This was done the right way as per CVS manual. Now we have two totally unrelated (from the CVS point of view) files: compiler.lisp and compiler.lsp. Actually, from the human point of view, these two are the different names of the same file, and being able to see the change history of this file _is_ a reasonable and logical thing! * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR BAR.1.123 $ cvs co -p -r 1.321 FOO FOO.1.321 $ diff BAR.1.123 FOO.1.321 -- etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) It's trivial to undo too -- the same way you undo any commit. okay. I _really_ do need this, and I will greatly appreciate an instruction on how to do this. Let me repeat: I have two files: compiler.lsp,v (with _many_ revisions) and compiler.lisp,v (with even _more_ revisions). I need to create a file compiler.lisp,v with _all_ these revisions, sequentially, first those from compiler.lsp,v, then from compiler.lisp,v. The only thing I can think of is: check out compiler.lsp and patch it, one by one, with all the patches that went into compiler.lisp, then go (using shell) into the CVS repository and rename compiler.lsp,v to compiler.lisp,v. The problem is that there are 64 such files, so this process will have to be automated somehow. BTW, is there any difference, from the CVS POV, between $ cvs ci -m mesg FOO BAR and $ cvs ci -m mesg FOO $ cvs ci -m mesg BAR ? the reason I am asking is that some files have been checked in together, so I will need to do some trickery to check the diffs into the old names together too. The problem is that I do not always have shell access - then I am stuck. You don't need to have shell-level access to the repository. this is very nice to hear. could you please tell me what to do? I hope I made my needs quite clear already. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ The program isn't debugged until the last user is dead. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: commit as root.
Hello everybody! I have a question. I need to work as root in a specific project. (I would try to find another solution, frankly) But, when I try to commit the modified files, I get a message telling that commit cannot be done as root. Are you using the :ext: protocol, or direct file access? If the latter, switch to :ext:. If the former, are you using rsh (boo! hiss! all the more if you're root, although usually root acccess for the r-commands is disabled)? If so, put something like the following in your .ssh/config: Host rootcvs HostName some.machine.co.uk User root Then check-out as: cvs -d ':ext:rootcvs:/path/to/cvsroot' co the-module (and/or change the contents of CVS/Root to this above string). From this on, things should work, provided that ssh allows root access (which I'm not at all sure about). You will probably want to add localhosts's identity.pub to cvsroot host's ~root/authorized_hosts, and also you'll want to run an ssh-agent to take care of passwords. Cheers, Philip -- The mail transport agent is not liable for any coffee stains in this message - Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify
Check out the loginfo file from your $CVSROOT
Add the following information at the end of the file:
ALL (echo ; id; echo %{sVv}; date; cat) | mailx -s subject in email
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
DEFAULT (echo ; id; echo %{sVv}; date; cat) $CVSROOT/CVSROOT/commitlog
Regards,
ar2kcm
--
Please tell me how I configure the notify CVS admin file along with any
other files to send e-mail to myself or other development personnel in
the event of changing and commiting source files.
Jeff
___
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: How to lock CVS for check-in
[ On Thursday, October 11, 2001 at 11:11:21 (+0530), Shubhabrata Sengupta wrote: ] Subject: Re: How to lock CVS for check-in At least in pserver access it is and I think it is also available in for local repository access as well. I am not sure about :ext: access though. I agree that its contents and its structure is entirely internal to CVS and may change without notice from one CVS release to another. I do not write anything into CVS/Entries at all - I use it to read the branch name of the file that is being committed. So that way there is very little danger of corrupting that file. Of course I make assumptions about the structure of the file and that may change from one CVS release to another - I am ready to change the regex I use to grep the branch name when that happens. The advantages I get from controlling access to branches through commitinfo script outweighs the risk in my case. Then is it not better to improve the commitinfo interface so that access to the raw CVS/Entries file is not necessary? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Why can't root check in files?
[ On Thursday, October 11, 2001 at 15:37:47 (+1000), [EMAIL PROTECTED] wrote: ] Subject: Re: Why can't root check in files? However, I still think that I'm onto something good here - the cvs control of Unix config files. Unfortunately, this sensible cvs feature utterly prevents me from providing this useful facility. You need to use some intermediate build process, which when necessary must be run as the superuser, to install your config files into their final resting place. Cfengine is one such solution to do this. However the maintenance of the source files and commits of their changes to CVS must be done by a real user-id, i.e. some user-id that represents exactly one real-world person. This is how accountability is maintained. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! Unless and until you understand this you will not understand how CVS manages change and how filenames are used within CVS. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 01:59:20 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] And not only do you lose the ability to get a file's entire version history with a single cvs log, That is not a loss -- it is a gain. You have it backwards. you also have added to a file's revision history all of the unwanted stuff from a previous incarnation that was renamed away. Well, yes, that's a bit of a bug, but we've discussed the obvious and very easy solution several times in the past Defending the ambiguity of the histories of logically different files that happen to share a path at one time or another, and the fragmentation of a file's entire version history is nonsensical. Since you've never really understood how CVS manages change and how filenames are used within CVS, this strange is not unsurprising. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? this is the same file. no, actually it is not. You are not properly understanding how CVS uses filenames and how it manages change to those files. CVS tracks changes to the contents of files by using their filenames as anchors in the directory structure. It knows nothing of what's in the files though, nor of their relationship to each other (except of course for their names and their hierarchical position in an underlying directory structure). It does this by effectively taking snapshots of the contents of the files and storing them in RCS files in the repository. The repository directory structure is laid out exactly as the working directory's structure is so as to make all of its operations one-to-one on each file in a module (with the exception of some optimisations it uses in the repository to avoid wasting time on dead files). If you take away a file then CVS marks it as dead and stops copying its old contents to working directories. If you add a file CVS starts tracking changes to that file (again if it was previously dead). There is no concept of a rename because CVS does not try to intuit that a newly added file's contents look a lot like some other removed file's contents. Just as in any simple relational database there is only an add and a delete operation and change is expressed through a combination of these operations. If you wish to remember that you've moved the contents of one file to another file then you need to do this in the same way you remember any other change -- i.e. with a commit comment. to use a very specific example: CLISP (http://clisp.cons.org) used lsp extension for CL files but switched to lisp a couple of years ago. Hmmm that's a very outrageous example of an idiotic change with no productive end result. This was done the right way as per CVS manual. Now we have two totally unrelated (from the CVS point of view) files: compiler.lisp and compiler.lsp. Actually, from the human point of view, these two are the different names of the same file, and being able to see the change history of this file _is_ a reasonable and logical thing! CVS is simply not designed to manage such large-scale renames. They are far beyond the design goals of a simple file handling tool like CVS. The most obvious logical approach to renaming those files would have been to add another intermediate step to your build process to do the rename at build time. The effect on the revision tracking of such a grand renaming is really no different than changing all the white space or indentation inside of every file. No change control tool, especially none which has zero understanding of the semantics of the files it manages, can cope in either of these examples. In other words for the example you describe the result is illogical from the very beginning -- to ask for CVS to now treat two different files as one is therefore equally illogical. Such structural changes to a project are usually best done at a major milestone (eg. just after a major release) and at least with CVS are usually handled best by starting fresh with a new module. That way you are not tempted to do things that would be illogical in the first place. The same is true with SCCS and RCS, and no doubt with TCCS, PRCS, Aegis, Perforce, and other similar tools too. * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR BAR.1.123 $ cvs co -p -r 1.321 FOO FOO.1.321 $ diff BAR.1.123 FOO.1.321 Huh? You have your result! What are you asking? CVS is not a programming language. Do we have to add that to the manual too?!?!?! Why is it that people are often blinded to the obvious when they are given a tool that combines many operations but not all operations? Perhaps everyone should do without RCS and without CVS for some small project and track every change to every file manually for a time. Then you would not so easily forget how to do such things when you use CVS! -- etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) It's trivial to undo too -- the same way you undo any commit. okay. I _really_ do need this, and I will greatly appreciate an instruction on how to do this. Let me repeat: I have two files: compiler.lsp,v (with _many_ revisions) and compiler.lisp,v (with even _more_ revisions). I need to create a file compiler.lisp,v with _all_ these
Re: cvs exit status
[ On Wednesday, October 10, 2001 at 14:43:14 (-0700), Paul Sander wrote: ] Subject: Re: cvs exit status What happens on a Unix system when the exit status exceeds 127? It overflows. Well, actually it'll depend on a number of factors. I suspect the result is literally undefined from the standards point of view. In many systems I suspect it will be confused with a signal having been delivered. In all cases I suspect there's only one chance in 127 of the overflow resulting in an apparent success. I'm too lazy to write the trivial test case though :-) An incremented exit status can (and does) report success in the presence of failures. What a bogus worry! Do you have an example of an actual code path in CVS which can easily cause such an overflow? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Howto solve this in cvs ?
[ On Monday, October 1, 2001 at 09:12:24 (+), Gerhard Ahuis wrote: ] Subject: Re: Howto solve this in cvs ? Greg A. Woods [EMAIL PROTECTED] wrote: For many of the same reasons it's literally impossible to ever have true multi-vendor support too -- all the benefits of cvs import are completely impossible to achieve with multiple vendor branches. You can do multi-vendor tracking manually, but it's one hell of a lot more work (more work even than managing several variant branches in a locally initiated project)! There are not many files, so if you can give me some hints to let a second vendor branch showup on a normal cvs branch and not on the main, I will be very thankfull. Well, it's really quite straight forward. You simply have to create normal branches for each vendor, and corresponding working directories for each, and then manually commit and tag each new release on each release. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to lock CVS for check-in
Greg, Are you arguing that this functionality be added as part of standard CVS in a future release (which I would prefer) or are you simply suggesting to Shubhabrata to change the CVS code for his or her own needs? -Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 11, 2001 9:58 AM To: CVS-II Discussion Mailing List Subject: Re: How to lock CVS for check-in [ On Thursday, October 11, 2001 at 11:11:21 (+0530), Shubhabrata Sengupta wrote: ] Subject: Re: How to lock CVS for check-in At least in pserver access it is and I think it is also available in for local repository access as well. I am not sure about :ext: access though. I agree that its contents and its structure is entirely internal to CVS and may change without notice from one CVS release to another. I do not write anything into CVS/Entries at all - I use it to read the branch name of the file that is being committed. So that way there is very little danger of corrupting that file. Of course I make assumptions about the structure of the file and that may change from one CVS release to another - I am ready to change the regex I use to grep the branch name when that happens. The advantages I get from controlling access to branches through commitinfo script outweighs the risk in my case. Then is it not better to improve the commitinfo interface so that access to the raw CVS/Entries file is not necessary? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to lock CVS for check-in
GAW == Greg A Woods [EMAIL PROTECTED] writes: GAW [ On Thursday, October 11, 2001 at 08:24:11 (+0530), Shubhabrata GAW Sengupta wrote: ] Subject: Re: How to lock CVS for check-in Wondering why this enhancement is needed in the commitinfo interface when you can always get the branch information out of the CVS/Entries file which is always available to the commitinfo script. GAW I'm not sure the CVS/Entries file is always available, and in any GAW case accessing it directly is a very very very bad hack. Its GAW contents should be private and for CVS internal use only. The fact GAW that some of its structure is documented in the manual is not GAW permission to go mucking about in it unless you're cleaning up some GAW form of corruption or another. So what do _you_ recommend for implementing branch locking? ...Jake -- Jake Colman Principia Partners LLC Phone: (201) 946-0300 Harborside Financial Center Fax: (201) 946-0320 902 Plaza Two E-mail: [EMAIL PROTECTED] Jersey City, NJ 07311 www.principiapartners.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify
On Thu Oct 11 2001, 10:31, Postek, Jeffery [EMAIL PROTECTED] wrote: Please tell me how I configure the notify CVS admin file along with any other files to send e-mail to myself or other development personnel in the event of changing and commiting source files. http://www.cvshome.org/docs/manual/cvs_18.html#SEC170 -- Matt http://www.faradic.net/~mmcclure/ I don't believe in rivalries. I don't believe in curses. Wake up the damn Bambino, maybe I'll drill him in the (behind). -Pedro Martinez ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! It's irrational to want the present implementation of a tool to do something that it isn't designed to do. CVS cannot represent the idea that BAR was once called FOO; that they are semantically intended to be the same object. But it's not illogical to *want* the capability in a version control tool. In a version control tool that has the capability, the user can see the entire history of FOO, going back to the point where it was renamed to BAR and beyond. The rename is just another historic event that is tracked, and the path name of the file is just another property. There is nothing illogical about it. You should accept that some people do not form a religious belief system around the capabilities of a software system. Unless and until you understand this you will not understand how CVS manages change and how filenames are used within CVS. Really? So until you wholeheartedly accept the limitations of a system the point that you can't imagine or want anything else, you can't understand that system? I believe that you only need to undersatnd and accept the limitations in order to properly *use* the system in the way it was designed. There is no need to accept those limitations for any other purpose, religious or whatever. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Anyone have VSS2CVS?
The site for vss2cvs (http://www.laine.org/cvs/vss2cvs/) is down, and judging by a previous message to this mailing list (http://mail.gnu.org/pipermail/info-cvs/2001-September/019557.html) has been since at least 4 Sep 2001. Does anyone have a copy of this script that they could email, or better yet, post somewhere? Thanks. BTW, I know there is an old version of it at http://alexm.here.ru/cvs-nserver/download/contrib/vss-to-cvs/jnairn/ but this is an old unenhanced version. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 13:47:09 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? this is the same file. no, actually it is not. yes, actually it is. you want me to look at the world through the tool-imposed blinders. no way. these files are the same, period. the issue is that CVS does not recognize that. Actually, now that the damage (i.e., the right way - cvs add/rm) has been done, CVS really has no reason to recognize the truth and admit that the files are the same. But calling cvs add/rm the right way instead of adding cvs mv is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. CVS tracks changes ... thanks for repeating this. actually, I knew all this, but it was nice to here that my knowledge was correct. to use a very specific example: CLISP (http://clisp.cons.org) used lsp extension for CL files but switched to lisp a couple of years ago. Hmmm that's a very outrageous example of an idiotic change with no productive end result. you do not have to be rude. you do not know all the circumstances. I was not the one who did it. In the similar situation I did the right thing - the renaming at the file-system level, not the CVS level. This was done the right way as per CVS manual. Now we have two totally unrelated (from the CVS point of view) files: compiler.lisp and compiler.lsp. Actually, from the human point of view, these two are the different names of the same file, and being able to see the change history of this file _is_ a reasonable and logical thing! CVS is simply not designed to manage such large-scale renames. They are far beyond the design goals of a simple file handling tool like CVS. why? why can't cvs mv rename the *,v file? The effect on the revision tracking of such a grand renaming is really no different than changing all the white space or indentation inside of every file. I do not buy this. renaming a file does not change it's contents. Such structural changes to a project are usually best done at a major milestone (eg. just after a major release) and at least with CVS are usually handled best by starting fresh with a new module. huh? you mean CVS is no designed to keep the changes over many years and releases?! That way you are not tempted to do things that would be illogical in the first place. The same is true with SCCS and RCS, and no doubt with TCCS, PRCS, Aegis, Perforce, and other similar tools too. Okay. I have never used TCCS, PRCS, Aegis, Perforce and SCCS. Emacs has `vc-rename-file' and it supports both RCS and SCCS. Yes, this might not be native operations, but _this can be done_. MS SourceSafe also can rename a file. Thus, of all the tools accessible to me, only CVS refuses to rename files. Would you like to use a file system which lacked rename(2) syscall and instead required one to do the following: $ cp FOO BAR $ rm FOO Let me repeat again: file renaming is a reasonable operation and it must be supported in a reasonable way. Just like cp+rm is not a reasonable replacement for mv, cvs add/rm is not a reasonable replacement for cvs mv. * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] Bull. It's trivial to do. please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR BAR.1.123 $ cvs co -p -r 1.321 FOO FOO.1.321 $ diff BAR.1.123 FOO.1.321 Huh? You have your result! What are you asking? I am asking that I do not have to be forced to jump over my head to achieve a trivial result. Let me repeat: I have two files: compiler.lsp,v (with _many_ revisions) and compiler.lisp,v (with even _more_ revisions). I need to create a file compiler.lisp,v with _all_ these revisions, sequentially, first those from compiler.lsp,v, then from compiler.lisp,v. I think you are asking the wrong question. You have not stated the base requirement which seems to be driving your desire to do this. I want to be able to see the change history for compiler.lisp c. If your goal is simply to forget that you ever had *.lsp files then obviously it would have been easier to simply rename them in the repository. yes of course! but the mistake has been done already, long ago, and I wish I could undo it now. The best process for your situation depends on many factors you have not described to us, such as whether or not you have other active branches, and whether or not you have previous releases that must be retained, and also whether or not you have renamed any other files in the past too. there are no branches, but there are many tags
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? this is the same file. no, actually it is not. It's only not the same file because of the braindamaged version control system which cannot represent that semantic idea! As far as the user is concerned, it is the same file, under a different name. Merely, the software has failed to capture the user's perfectly sensible idea. Instead, it provided a half-baked emulation: delete the old, recreate under new name. This breaks seriously, for instance, under merging. Suppose work takes place on FOO on a branch. Then on the trunk FOO is removed, and a BAR is created with identical contents, in order to emulate a rename. When the branch is later merged, the FOO patches will not be applied to BAR. Moving the patches to BAR will require error-prone manual work. This should be pereceived as enough of a problem to completely deter clueful users form trying to rename files. The best way to view CVS is that it does not handle renames at all, so don't even think about ever doing it using *any* of the methods recommended in the manual. I can live without being able to view the complete history of the object in one piece. But the other breakage, in particular merging, makes it totally unacceptable to do a rename. I accept the limitation only because CVS has open source code, a suitable redistribution license, good reliability and a set of capabilities that is good enough for many purposes. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Sam Steingold wrote: * In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 13:47:09 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? this is the same file. no, actually it is not. yes, actually it is. you want me to look at the world through the tool-imposed blinders. In fact I have the same impression. It consistently *appears* as if Greg wants people to accept the limitations of CVS to an irrational degree. In his view, it appears, I must not only accept that CVS doesn't handle renames, but also stop wanting a version control system that handles renames. In fact, I must stop seeing file renames as legitimate version control events. Otherwise, presumably, my mind will somehow go to pieces imagining something that the selected tool doesn't provide. This may be far from the intent, but it sure reads that way, Greg! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to lock CVS for check-in
[ On , October 11, 2001 at 14:41:17 (-0400), Jake Colman wrote: ] Subject: Re: How to lock CVS for check-in So what do _you_ recommend for implementing branch locking? I don't recommend implementing branch locking in CVS at all. Anyone who thinks they need it probably has far larger problems that branch locking won't really solve in the first place. It's a bad workaround to the wrong problem. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Removing a repository
Hello! I'm new to CVS and recently started a project at www.sourceforge.net I created a test repository (ok, I really didn't know what I did ;) and now I want to delete this unused repository. How can I do this? Next question: I created the main repository but all files have the revision number 1.1.1.1. Why not 1.1 and how can I reset the revision number? Hope you can help me :) Check out www.sourceforge.net/projects/lanintern Thanks in advance Marian ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 19:15:30 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] It's irrational to want the present implementation of a tool to do something that it isn't designed to do. CVS cannot represent the idea that BAR was once called FOO; that they are semantically intended to be the same object. But it's not illogical to *want* the capability in a version control tool. Are we talking about CVS, or some fictional tool here? I'm talking about CVS. In a version control tool that has the capability, the user can see the entire history of FOO, going back to the point where it was renamed to BAR and beyond. The rename is just another historic event that is tracked, and the path name of the file is just another property. There is nothing illogical about it. Ah, so you're not talking about CVS -- why are you posting here then? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 19:51:13 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] It's only not the same file because of the braindamaged version control system which cannot represent that semantic idea! As far as the user is concerned, it is the same file, under a different name. Merely, the software has failed to capture the user's perfectly sensible idea. Instead, it provided a half-baked emulation: delete the old, recreate under new name. I think you have extremely unrealistic expectations. I suggest you do a survey of similar tools and count the number that can do exactly what you want. I suspect you'll find that number to be quite low and almost certainly only include high-end commercial packages. This breaks seriously, for instance, under merging. Suppose work takes place on FOO on a branch. Then on the trunk FOO is removed, and a BAR is created with identical contents, in order to emulate a rename. When the branch is later merged, the FOO patches will not be applied to BAR. Indeed -- you've spotted one of the many limitations of CVS. While it likes to do merging, a lot, it doesn't always know when to do merges and it cannot be relied upon to do all merges and to always do them correctly. The programmer is still ultimately responsible for all merges. Moving the patches to BAR will require error-prone manual work. Merging is always potentially error prone. Manual merging is often almost ininitely _LESS_ error prone than automated merging. Why the heck do you think some people oppose CVS so much? It's primarily because they don't trust automated merging It is certainly not a bad thing that CVS forces you do to some manual merging. It might be nice if it could store more metadata to suggest to you when you have to do a manual merge, but it doesn't and so you must keep track yourself and verify that the results of all merges include all of the changes you intend them to keep. This should be pereceived as enough of a problem to completely deter clueful users form trying to rename files. The best way to view CVS is that it does not handle renames at all, so don't even think about ever doing it using *any* of the methods recommended in the manual. Well, if you have lots of branches you want to avoid renames as much as possible, but it's not a dead-end un-penetrable brick wall -- a little bit of consiousness is all it takes to work around this limitation. The biggest trick is to learn to plan properly. If you do your renames at major milestone markers in your development process then you can likely eliminate most of the need to merge changes across the renames. This isn't rocket science -- it's really quite basic accounting. There's really nothing new about this limitation -- any tool more primitive than CVS would have similar limitations and any experience developer should know that big changes which have no semantic meaning must be planned carefully so that they don't obscure other changes. People did change management manually for decades. CVS can do much of the really mundane work, but it is not a complete change management system. I can live without being able to view the complete history of the object in one piece. But the other breakage, in particular merging, makes it totally unacceptable to do a rename. I think you've got big blinders on. If you expect one tool to suddendly do everything and totally eliminate any and all manual change management then you will likely never be satisified. Take your blinders off and learn to do some of the tasks the hard way -- it really isn't all that hard and so long as you don't do too many renames in places where merging will eventualy be necessary you won't have very much trouble managing your changes around renames. I accept the limitation only because CVS has open source code, a suitable redistribution license, good reliability and a set of capabilities that is good enough for many purposes. In the freeware markeplace there's always room for more tools! :-) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Help with CVS design
Due to the constraints of some software that we have to use, I am forced into a particular directory structure. Multiple developers may need to work on the same file. Each developer has their own working directory. For example: /export/component/src this is the component src directory /export/component/user1 these are where the developers are editing their own copies of source /export/component/user2 I am trying to automate the check in/ checkout process as much as possible. I want to use the trunk as the baseline and branches for changes. My checkout script does the following: 1. Checkout the file from CVS into the component src directory a) If a branch tag is specified, check out from the branch b) If no tag, check out from the trunk 2. Copy the file to the correct user directory. The developer then makes changes and my check in script does the following 1. copy the files from the user to the component/src directory 2. Check the files into CVS using a branch tag specified The merge back to the trunk comes later. I use import to get all the files in the component/src directory. For my checkout, I am doing: cvs checkout -d /component/src FileName.cpp if no branch is specified. cvs checkout -r CCN1 -d /component/src FileName.cpp if a branch CCN1 is specified. In the first case, I want to get the latest version off of the trunk. In the second case, I want to get the latest version off of the CCN1 branch. Both these statements appear to be checking out where ever the head is in the current working directory. How do I make sure that I am getting the version that I want? My Check in script does the following: cvs tag -b CCN1 FileName.cpp); cvs update -r CCN1 FileName.cpp cvs commit -r CCN1 -m message FileName.cpp What I want to happen is this: Regardless of whether the file was checked out from a branch or the trunk, commit the file with the branch specified. If the branch already exists, I want the commit to be the latest version of the branch. If it does not exist, I want to create a new branch, off of the trunk. Once a commit is done I want the developers to checkout again prior to editing files. Obviously I am missing some subtleties of how CVS works and would greatly appreciate any assistance. -Tim ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Yeah, file locking is really unproductive. I just love wasting all that time tryin' to figure out why the merge didn't happen and do it all by hand. My boss really likes all the extra cost too. [EMAIL PROTECTED] wrote: The most you could hope for in CVS is to install a patch that allows advisory locks -- reserved locks are counter to the purpose of CVS. You can find a version of the patch (I think against cvs-1.11.1) at SourceForge under project RCVS. Once the patch is installed, tell the users that they must have cvs edit -c and cvs ci -c in their ~/.cvsrc files. Be sure to turn on notification as well. The process they should follow is: 1. When intending to modify a file for checkin, cvs edit the file. 2. If the files are being edited by others, contact the other parties to minimize the chances of conflicts. 3. If the chances of conflicts is minimal or the others cannot be contacted, cvs edit -f the files. 4. If one receives notification about an as-yet-unknown edit, contact the editor to help minimize the chances of conflicts. Noel Hello all, Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? If there is any info., please email to [EMAIL PROTECTED] Many thanks in advance Andrew ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to lock CVS for check-in
[EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 14:41:17 (-0400), Jake Colman wrote: ] Subject: Re: How to lock CVS for check-in So what do _you_ recommend for implementing branch locking? I don't recommend implementing branch locking in CVS at all. Anyone who thinks they need it probably has far larger problems that branch locking won't really solve in the first place. It's a bad workaround to the wrong problem. Speaking as someone who recently came very close to having to use cvs co -p to undo someone else's mistake (they were workign on the wrong branch by mistake) I disagree. -- James Youngman Manchester, UK. +44 161 226 7339 PGP (GPG) key ID for [EMAIL PROTECTED] is 64A95EE5 (F1B83152). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
The RCVS part on source forge seems to be dead. Is anyone really developing locking for CVS? [EMAIL PROTECTED] wrote: The most you could hope for in CVS is to install a patch that allows advisory locks -- reserved locks are counter to the purpose of CVS. You can find a version of the patch (I think against cvs-1.11.1) at SourceForge under project RCVS. Once the patch is installed, tell the users that they must have cvs edit -c and cvs ci -c in their ~/.cvsrc files. Be sure to turn on notification as well. The process they should follow is: 1. When intending to modify a file for checkin, cvs edit the file. 2. If the files are being edited by others, contact the other parties to minimize the chances of conflicts. 3. If the chances of conflicts is minimal or the others cannot be contacted, cvs edit -f the files. 4. If one receives notification about an as-yet-unknown edit, contact the editor to help minimize the chances of conflicts. Noel Hello all, Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? If there is any info., please email to [EMAIL PROTECTED] Many thanks in advance Andrew ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 13:03:50 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! Could you please elaborate? _Why_ is it illogical? _Why_ is it unnecessary? Let me try to repeat: FOO and BAR here are the same file (like compiler.lisp and compiler.lsp). If FOO is renamed to BAR when it is at 1.125, then the change from FOO 1.123 to BAR 1.3 is a matter of 4 modifications: 1. FOO 1.123 -- FOO 1.124 2. FOO 1.124 -- FOO 1.125 == BAR 1.1 3. BAR 1.1 -- BAR 1.2 4. BAR 1.2 -- BAR 1.3 Why can't I see the log for all of them in one command? Consider a versioning file system which has a native idea of file version. I can rename file FOO;latest to BAR;latest, keeping the older versions of FOO named FOO;1, FOO;2 c. - this corresponds to the CVS method (rm/add). But I also can rename _all_ version of FOO to BAR. This _is_ a reasonable thing to do. Why can't I do it with CVS? Please note that the answers like this is not how CVS manages change! are not very convincing, because the natural retort is then maybe CVS manages change incorrectly? Please tell us _why_ the request for the CVS command mv, which would rename the *,v file and replace the CVS/Entries entry is unreasonable. (Oh yeah, CVSROOT/history should also be suitably modified and a record of the renaming to allow for undoing it should also be added. But is these are too hard to implement, forget it and stick with a simple mv FOO,v BAR,v). And while I am talking about undoing, why can't a revision be removed from the CVS? just like I can remove a revision in a versioning file system, I should be able to remove a revision from the CVS. Don't get me wrong. CVS is a great tool. Let's make it even better! -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ The paperless office will become a reality soon after the paperless toilet. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On Thursday, October 11, 2001 at 19:15:30 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] It's irrational to want the present implementation of a tool to do something that it isn't designed to do. CVS cannot represent the idea that BAR was once called FOO; that they are semantically intended to be the same object. But it's not illogical to *want* the capability in a version control tool. Are we talking about CVS, or some fictional tool here? I'm talking about CVS. Even if you are talking about CVS, you can still wish that it did something for you that it does not. Users of existing software tend to have requirements that are not met by that software, and which sometimes appear in new revisions. That is how progress takes place, in part. In a version control tool that has the capability, the user can see the entire history of FOO, going back to the point where it was renamed to BAR and beyond. The rename is just another historic event that is tracked, and the path name of the file is just another property. There is nothing illogical about it. Ah, so you're not talking about CVS -- why are you posting here then? To counter your insulting claim that wishing for a hygienic renaming feature is illogical. Since that claim was posted here, my reply is posted here also. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] But calling cvs add/rm the right way instead of adding cvs mv is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. You're not making sense. You need to understand the much deeper issues of trying to include rename information in a change control tool, You really cannot add such a feature to a file-based change tracking tool -- doing so takes you far away from what CVS is. you do not have to be rude. I wasn't -- I was merely pointing out that such an example is not relevant to this discussion since it is far beyond what most any file-based change control tool can ever do. you do not know all the circumstances. I was not the one who did it. I didn't claim to know the circumstances, nor who did it -- that's all mostly irrelevant. In the similar situation I did the right thing - the renaming at the file-system level, not the CVS level. Well, whether that would have been the right thing or not depends on several other factors. why? why can't cvs mv rename the *,v file? Nope -- no file-based change control tool can. You have to add a whole mess of meta-data on top, and the more you think about all the corner cases and side effects, the deeper the pile gets. Soon you end up building a system that's completely the opposite of a file-based change control tool -- i.e. one that constructs files out of sets of changes that are probably stored in a more sophisticated database than any unix-like filesystem can ever be on its own. The effect on the revision tracking of such a grand renaming is really no different than changing all the white space or indentation inside of every file. I do not buy this. renaming a file does not change it's contents. but the EFFECT (on the change management process) is the same!!! Unless you understand this you will fail to understand the larger issue here! Such structural changes to a project are usually best done at a major milestone (eg. just after a major release) and at least with CVS are usually handled best by starting fresh with a new module. huh? you mean CVS is no designed to keep the changes over many years and releases?! It all depends on many many many factors. In a simple and relatively straight forward project it works very well over extended periods of time. Take NetBSD or FreeBSD, or even the CVS-II source itself, for example Emacs has `vc-rename-file' and it supports both RCS and SCCS. Yes, this might not be native operations, but _this can be done_. I think you don't understand the larger issues here. What vc-rename-file does breaks all kinds of things in the larger SCM picture! It is a cheap hack that wise people would only use in very limited circumstances. Thus, of all the tools accessible to me, only CVS refuses to rename files. CVS refuses to rename files because the CVS designers were aware of all the deeper issues and they didn't want to create a situation worse than the current alternative. Would you like to use a file system which lacked rename(2) syscall and instead required one to do the following: $ cp FOO BAR $ rm FOO well as a matter of fact the rename(2) call is a recent addition BUT, You're trying to compare totally unrelated things here -- it might look so simple on the surface, but when you have to keep track of such operations over time requires much more than a simple rename command! please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR BAR.1.123 $ cvs co -p -r 1.321 FOO FOO.1.321 $ diff BAR.1.123 FOO.1.321 Huh? You have your result! What are you asking? I am asking that I do not have to be forced to jump over my head to achieve a trivial result. Jump over your head? What kind of nonsense is that? The procedure is trivial! Why are you complaining about something so simple and obvious? Just do it! yes of course! but the mistake has been done already, long ago, and I wish I could undo it now. be careful what you wish for -- you may only create a worse nightmare. If I were you I would break from the past and start fresh. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to lock CVS for check-in
Greg, I don't know your environment, but branch locking is a common mechanism for allowing read-only access to a branch. It's really quite useful and given the high frequency that this issue pops up in this forum, I'm not alone in my view. I'm not knocking CVS. Nor am I knocking anyone who finds no use in it. But in companies that have a sizable development team, especially one that's globally dispersed, and need to many support back releases, branch locking provides a good solution. Regardless of your SCM needs, there are many of us that would be better off having branch locking as a standard feature in CVS. If adding some form of branch locking directly or indirectly (e.g., changing the interface to commitinfo) causes other problems, I'll live without it, add a kludge or move to a tool that supports it. I'm okay with those choices, IF there is a technical reason for CVS to not support branch locking. You say that it solves the wrong problem. Given an example from my day yesterday, a developer was swapping between a couple of workspaces to compare what gets built in a release that is to ship in a few months with one that shipped months back. She accidentally checked in part of a new feature in a back release. Hey, she's human and fifteen minutes later I had the problem fixed. Our organization is large enough that this is a common problem, not because of one or two idiots, but because of the shear number of developers, with differing levels of experience, and number of branches, this problem keeps popping up. The right solution to the right problem may be to genetically engineer developers that don't make mistakes, but it might be a bit easier to implement branch locking. -Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 11, 2001 1:46 PM To: Jake Colman Cc: [EMAIL PROTECTED] Subject: Re: How to lock CVS for check-in [ On , October 11, 2001 at 14:41:17 (-0400), Jake Colman wrote: ] Subject: Re: How to lock CVS for check-in So what do _you_ recommend for implementing branch locking? I don't recommend implementing branch locking in CVS at all. Anyone who thinks they need it probably has far larger problems that branch locking won't really solve in the first place. It's a bad workaround to the wrong problem. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 20:15:10 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In fact I have the same impression. It consistently *appears* as if Greg wants people to accept the limitations of CVS to an irrational degree. Well, if you don't want to accept it, what, EXACTLY, are you going to do about it? Do you have a viable alternative tool waiting in the wings? If so then why haven't you proposed it as an alternative? In his view, it appears, I must not only accept that CVS doesn't handle renames, but also stop wanting a version control system that handles renames. That's not what I said at all. In fact, I must stop seeing file renames as legitimate version control events. I certainly didn't say that either. CVS doesn't support renames, but it provides enough mechanism to make it relatively easy to manually track renames and to manually perform operations on renamed files that CVS itself can never do internally. Anything that can be done manually can, obviously, also be scripted. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removing a repository
In article 9q501b$d03$00$[EMAIL PROTECTED], Marian Seitner wrote: Hello! I'm new to CVS and recently started a project at www.sourceforge.net I created a test repository (ok, I really didn't know what I did ;) and now I want to delete this unused repository. How can I do this? Next question: I created the main repository but all files have the revision number 1.1.1.1. Why not 1.1 and how can I reset the revision number? The 1.1.1.1 version number is a an internal CVS feature having to do with vendor branching. Your newly imported files have both a 1.1 and a 1.1.1.1 revision number. Don't worry about it, when you commit new versions to these files, they will go to 1.2, and the next vendor import will go to 1.1.1.2. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 17:08:07 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: I suggest you do a survey of similar tools and count the number that can do exactly what you want. I suspect you'll find that number to be quite low and almost certainly only include high-end commercial packages. As I said in another message, in Emacs, M-x vc-rename-file RET will work when the back-end is RCS or SCCS, but not when it is CVS. I have no idea what SCCS is, but I thought that RCS was _more_ primitive than CVS. All the problems you are talking about here (merging c) arise for one simple reason - you do not have cvs mv and you make people think that cvs add/rm has anything to do with renaming. There are two levels to renaming: * you can go the filesystem way, do mv(1) and forget the old name completely, * or you can go the change management: way, and remember the old name(s), permitting undo c. Not providing _either_ is brain damage. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ .sigs are like your face - rarely seen by you and uglier than you think ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
* In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 17:51:02 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] But calling cvs add/rm the right way instead of adding cvs mv is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. You need to understand the much deeper issues of trying to include rename information in a change control tool, You really cannot add such a feature to a file-based change tracking tool -- doing so takes you far away from what CVS is. why? why? why can't cvs mv rename the *,v file? Nope -- no file-based change control tool can. You have to add a whole mess of meta-data on top, and the more you think about all the corner cases and side effects, the deeper the pile gets. Soon you end up building a system that's completely the opposite of a file-based change control tool -- i.e. one that constructs files out of sets of changes that are probably stored in a more sophisticated database than any unix-like filesystem can ever be on its own. why? why can't cvs mv just rename the *,v file? let me repeat: why can't cvs mv just rename the *,v file? The effect on the revision tracking of such a grand renaming is really no different than changing all the white space or indentation inside of every file. I do not buy this. renaming a file does not change it's contents. but the EFFECT (on the change management process) is the same!!! why? Emacs has `vc-rename-file' and it supports both RCS and SCCS. Yes, this might not be native operations, but _this can be done_. I think you don't understand the larger issues here. What vc-rename-file does breaks all kinds of things in the larger SCM picture! It is a cheap hack that wise people would only use in very limited circumstances. I am not saying I will be doing cvs mv twice a day. I have felt the need for it about twice in my life. The fact that CVS cannot do it is still haunting me. Thus, of all the tools accessible to me, only CVS refuses to rename files. CVS refuses to rename files because the CVS designers were aware of all the deeper issues and they didn't want to create a situation worse than the current alternative. what can be worse?! cut the socialist crap. remember the 2nd amendment, give me the damned gun and explain me that I should be careful not to shoot myself -- but let _me_ decide what I want to do. Would you like to use a file system which lacked rename(2) syscall well as a matter of fact the rename(2) call is a recent addition so? BUT, You're trying to compare totally unrelated things here -- it might look so simple on the surface, but when you have to keep track of such operations over time requires much more than a simple rename command! okay - so don't keep track! just rename the darn *,v files! yes, rename then would be global - all branches will be affected. so issue a warning! those who can be hurt by this will not use this. yes of course! but the mistake has been done already, long ago, and I wish I could undo it now. be careful what you wish for -- you may only create a worse nightmare. bull. I did a manual rename of *,v files in the CVS repository one. I have never had any problems with that. Everything works as expected. No problems. If I were you I would break from the past and start fresh. Don't be ridiculous. I have users to support. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! http://www.i-charity.com/go/israel Read what the Arab leaders say to their people on http://www.memri.org/ Live Lisp and prosper. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs exit status
--- Forwarded mail from Greg Woods: [ On Wednesday, October 10, 2001 at 14:43:14 (-0700), Paul Sander wrote: ] Subject: Re: cvs exit status What happens on a Unix system when the exit status exceeds 127? It overflows. Well, actually it'll depend on a number of factors. I suspect the result is literally undefined from the standards point of view. In many systems I suspect it will be confused with a signal having been delivered. In all cases I suspect there's only one chance in 127 of the overflow resulting in an apparent success. I'm too lazy to write the trivial test case though :-) An incremented exit status can (and does) report success in the presence of failures. What a bogus worry! Do you have an example of an actual code path in CVS which can easily cause such an overflow? Sure: # Create a test module cvs checkout CVSROOT echo foo foo CVSROOT/modules mkdir $CVSROOT/foo ( cd CVSROOT cvs commit -m Added test module modules ) # Populate the test module cvs checkout foo cd foo x=1 while [ $x -le 258 ] do fn=foo$x echo this is $fn $fn cvs add $fn x=`expr $x + 1` done cvs commit -m initial checkin cd .. # Checkout concurrent copy cvs checkout -d foo2 foo # Modify and commit the original checked-out copy cd foo x=1 while [ $x -le 258 ] do fn=foo$x echo appended $fn x=`expr $x + 1` done cvs commit -m made a change cd .. # Make a different change to the 2nd copy cd foo2 x=1 while [ $x -le 258 ] do fn=foo$x echo different change $fn x=`expr $x + 1` done # Overflow occurs here; an exit status less than 258 indicates an overflow. cvs update echo exit status is $? And if you don't like having 258 files in a single directory, feel free to partition the test module into a tree of smaller directories. It will not affect the outcome in any significant way. (Actually, the number of files that trips the overflow is much smaller; error codes are usually incremented more than once in CVS' error paths.) --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Anyone have VSS2CVS?
That did the trick. Much obliged. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Pratt Sent: Thursday, October 11, 2001 5:11 PM To: Alex Jacques Cc: [EMAIL PROTECTED] Subject: Re: Anyone have VSS2CVS? Alex, Try www.laine.org:8080/cvs/vss2cvs/ I think his ISP is blocking http inbounds on port 80. -Greg Alex Jacques wrote: The site for vss2cvs (http://www.laine.org/cvs/vss2cvs/) is down, and judging by a previous message to this mailing list (http://mail.gnu.org/pipermail/info-cvs/2001-September/019557.html) has been since at least 4 Sep 2001. Does anyone have a copy of this script that they could email, or better yet, post somewhere? Thanks. BTW, I know there is an old version of it at http://alexm.here.ru/cvs-nserver/download/contrib/vss-to-cvs/jnairn/ but this is an old unenhanced version. ___ 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: [kfogel@collab.net: Re: rename in cvs]
%% Sam Steingold [EMAIL PROTECTED] writes: sam Could you please elaborate? It is pointless to argue about this. Many have tried before you, and if history is any judge you will accomplish nothing in the attempt. sam Don't get me wrong. CVS is a great tool. Let's make it even sam better! I've said many times here before: Subversion will be ready long before you could enhance CVS to get these features, even without the flak you're sure to take for even suggesting it. Subversion is already self-hosting and they're working hard towards the 1.0 release (and those guys _do_ work hard; they get a phenomenal amount of work done every week). If you want advanced capabilities like directory versioning, head over to Subversion and spend your time helping there. It's been made quite clear (to me) that CVS is Done. It does what it does, and if you want anything different you should get a different tool. -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT--HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. If your question really is: Is anyone making locking a mainstream feature of CVS? Then I believe the answer is no. Despite the outcry to have this capability, no one with commit access to the definitive sources seems to be taking it seriously enough to apply Noel's patch (or implement other things that have been discussed over the years), and no one seems to be writing something else that does locking and supplies CVS' other useful features. --- Forwarded mail from [EMAIL PROTECTED] The RCVS part on source forge seems to be dead. Is anyone really developing locking for CVS? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On Thursday, October 11, 2001 at 20:15:10 (GMT), Kaz Kylheku wrote: ] In fact, I must stop seeing file renames as legitimate version control events. I certainly didn't say that either. That's great! I was hoping you'd be goaded into denying that you hold these extremist viewpoints, thereby clearing everything up. ;) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Sam Steingold wrote: * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: [ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] But calling cvs add/rm the right way instead of adding cvs mv is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. You need to understand the much deeper issues of trying to include rename information in a change control tool, You really cannot add such a feature to a file-based change tracking tool -- doing so takes you far away from what CVS is. why? Because you would have to either change the representation of the repository, or implement a whole indirection layer over CVS so that the repository contains only ``anonymous'' objects which are assigned to locations in a sandbox tree through some auxiliary binding. why can't cvs mv just rename the *,v file? Because then if you check out (or export) an old tagged build of the software, it will have the rename. And that will very likely break the old build. A fundamental principle of version control is that when you label some release of the software, it is fixed for posterity. Anyone can go back and retrieve that release exactly. This capability essential if you ever need to go back to that version and shoot off a bugfix branch, for instance. In CVS, you can no longer do this if you start moving around the *,v files. If you can't go back to tagged builds, then your version control system is reduced to a mere piece of collaboration ``groupware'' at best, and a file backup system at worst. ;) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[EMAIL PROTECTED] (Kaz Kylheku) writes: In article [EMAIL PROTECTED], Greg A. Woods wrote: Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! It's irrational to want the present implementation of a tool to do something that it isn't designed to do. You should accept that some people do not form a religious belief system around the capabilities of a software system. It's irrational to want the present implementation of the other half of this dialogue to do something that it isn't designed to do. -- Mark Jackson - http://www.alumni.caltech.edu/~mjackson Meeting the author, I think, is one of life's most reliably disappointing experiences. - Billy Collins ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Why can't root check in files?
On 10 Oct, Mike Castle wrote: On Thu, Oct 11, 2001 at 03:37:47PM +1000, [EMAIL PROTECTED] wrote: However, I still think that I'm onto something good here - the cvs control of Unix config files. Unfortunately, this sensible cvs feature utterly prevents me from providing this useful facility. Use something like GNU's cfengine (http://www.gnu.org/software/cfengine/cfengine.html) and put those configuration files under CVS control. I've looked at it. It is solving a somewhat different problem. It is not only far heavier tool than what I need, it's also more active (li kely to reset permissions to what you had laboriously constructed), and has a much larger learning curve. Hands up how many people are using cfengine on their home system? Using my script it takes 10 mins to put your system under CVS control. The learning curve in the simplest case is: $ su # cvs-etc If you already use cvs, then there is nothing else to learn. Check the CVS archives. Been discussed here several times in the past. :- I'd like to do that, but it looks like a project in itself. They're split up by month, so I have to check through 38 files by thread and taking a guess at the subject line. Like I said, a project in itself. Greg A. Woods replied to: However, I still think that I'm onto something good here - the cvs control of Unix config files. Unfortunately, this sensible cvs feature utterly prevents me from providing this useful facility. You need to use some intermediate build process, which when necessary must be run as the superuser, to install your config files into their final resting place. That's not actually true. I *have* a script that runs over a set of /etc-like directories and adds all the plain text files into a CVS archive, and populates the live area with CVS directories and .cvsignore files without altering any of the existing files. So, since they are in their final resting place, nothing else is needed. And from this point on, I can happily run cvs diff and see what has changed since last time, and then on a case by case basis make a decision about each file before I commit them. Except that I can't, because of this restriction in CVS. I also store the metadata so that *if I need to*, I can checkout the archive (as long as I'm root, so that I have permission), and run the metadata files which restores the metadata. I can't imagine why that would be required, really, since you have system backups anyway, and you wouldn't try to copy one system's config files on top of another. However the maintenance of the source files and commits of their changes to CVS must be done by a real user-id, i.e. some user-id that represents exactly one real-world person. You can't guarantee this, ever. The current scheme makes it the path of least resistance, but that's all. Here are some sample scenarios that show yhow the current scheme only promotes accountabiility, rather than guaranteeing it: 1) I walk up to someone else's machine and make changes and check them in. 2) I'm doing (1) with the full co-operation and agreement of the other person. 3) It's a login (the extreme example would be a guest account), which several people are using to collaborate. 4) I have su-ed from my identity to another. 5) I've written a setuid program that runs cvs operations so that they can pretend to be me. 6) I have write permission on the cvs file, hence the archive file, so I vi the files and change the data in the ,v file. There are probably other ways too. In all these cases (except 6), the ability to say I'm someone else is useful. If you really hate this idea, then record the user as real-user/claimed-user in the case where they use the hypothetical commit -u USER that I've suggested. This is how accountability is maintained. No, that's how accountability is maintained if no one does anything unusual. Think of it this way: the data you are storing could not be used in a court of law, could it? Anyway, I'll go and check the archives and see if I can make more sense of this, when I have a few hours spare. Thanks for your comments, luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
The patches are there for anyone to use. Last I heard, all that's stopping them from being included with the standard distribution are the lack of test and doc patches. You're welcome to work on them. Welcome to the world of open source. Noel The RCVS part on source forge seems to be dead. Is anyone really developing locking for CVS? [EMAIL PROTECTED] wrote: The most you could hope for in CVS is to install a patch that allows advisory locks -- reserved locks are counter to the purpose of CVS. You can find a version of the patch (I think against cvs-1.11.1) at SourceForge under project RCVS. Once the patch is installed, tell the users that they must have cvs edit -c and cvs ci -c in their ~/.cvsrc files. Be sure to turn on notification as well. The process they should follow is: 1. When intending to modify a file for checkin, cvs edit the file. 2. If the files are being edited by others, contact the other parties to minimize the chances of conflicts. 3. If the chances of conflicts is minimal or the others cannot be contacted, cvs edit -f the files. 4. If one receives notification about an as-yet-unknown edit, contact the editor to help minimize the chances of conflicts. Noel Hello all, Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? If there is any info., please email to [EMAIL PROTECTED] Many thanks in advance Andrew ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to lock CVS for check-in
[ On , October 11, 2001 at 22:27:38 (+0100), James Youngman wrote: ] Subject: Re: How to lock CVS for check-in Speaking as someone who recently came very close to having to use cvs co -p to undo someone else's mistake (they were workign on the wrong branch by mistake) I disagree. That particular command could not have caused any permanent damage, so I'm not really sure what you're so worried about. Far worse are operations which add, delete, or move, tags; but as I've mentioned several times again recently it would be very easy to add an additional access control for those kinds of things, at least on a per-repository basis, in much the same way the existing cvsadmin feature exists. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Thursday, October 11, 2001 at 21:33:05 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] To counter your insulting claim that wishing for a hygienic renaming feature is illogical. Since that claim was posted here, my reply is posted here also. Look if you want to discuss some mythical tool that you think should exist then why don't you go off to one of the forums more suited for that purpose? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs edit -c command
I don't know what you're talking about. I was able to get the reservations patch at http://sourceforge.net/tracker/download.php?group_id=4680atid=304680file_id=6141aid=422725 Noel There are no files to download in this project. Looks DOA. [EMAIL PROTECTED] wrote: The patch is available at SourceForge under project RCVS. The gist of the patch is: 1. cvs edit -c will abort the edit if another is editing the files. 2. cvs edit -f will force the edit. 3. cvs ci -c will abort the checkin if a valid edit does not exist on the files. Noel Does anyone know where I can find some info on this command and arguments. I can't seem to find it Thanks Curt Stanton ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 17:55:15 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] * In message [EMAIL PROTECTED] * On the subject of Re: [[EMAIL PROTECTED]: Re: rename in cvs] * Sent on Thu, 11 Oct 2001 17:08:07 -0400 (EDT) * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: I suggest you do a survey of similar tools and count the number that can do exactly what you want. I suspect you'll find that number to be quite low and almost certainly only include high-end commercial packages. As I said in another message, in Emacs, M-x vc-rename-file RET will work when the back-end is RCS or SCCS, but not when it is CVS. Do you have any clue at all what you're talking about? Do you really know what vc-rename-file does? Do you understand the temporal consequences of such an operation? It would seem not. I have no idea what SCCS is, but I thought that RCS was _more_ primitive than CVS. Well, CVS is little more than a simple integrated wrapper around RCS. It could have been built just about as easily on SCCS, which is really just a silghtly better (but a little more restricted) tool like RCS. CVS isn't really more or less primitive than RCS from an overal change management process perspective. All CVS does is make it possible to automate a number of RCS operations in a convenient manner. All the problems you are talking about here (merging c) arise for one simple reason - you do not have cvs mv and you make people think that cvs add/rm has anything to do with renaming. It's FAR deeper than that I'm afraid. Here's a simple cvs-mv script for you: #! /bin/sh # # cvs-mv -- for the command-line challenged # if [ $# -ne 2 -o ! -f $1 -o ! -f $2 ] ; then echo usage: cvs-mv oldfile newfile 21 exit 2 fi # oldpath=$1 newpath=$2 oldfile=$(basename $oldpath) newfile=$(basename $newpath) olddir=$(dirname $oldpath) newdir=$(dirname $newpath) cp $oldpath $newpath cd $olddir cvs rm -f $oldfile cd - cd $newdir cvs add $newpath cd - cvs commit -m renamed '$oldpath' to '$newpath' $oldpath $newpath There. Are you happy now? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to lock CVS for check-in
[ On Thursday, October 11, 2001 at 15:14:47 (-0700), Pyatt, Scott wrote: ] Subject: RE: How to lock CVS for check-in I don't know your environment, but branch locking is a common mechanism for allowing read-only access to a branch. Wel, DUH! :-) It's really quite useful and given the high frequency that this issue pops up in this forum, I'm not alone in my view. I think the right phrase would be: not alone in your confusion. I'm not knocking CVS. Nor am I knocking anyone who finds no use in it. But in companies that have a sizable development team, especially one that's globally dispersed, and need to many support back releases, branch locking provides a good solution. Do you have any idea how big the three main *BSD projects are, how widely diverse and dispersed their committers are? They seem to do well enough without branch locking. Regardless of your SCM needs, there are many of us that would be better off having branch locking as a standard feature in CVS. More likely it`s: many of you need to learn more about employing external process controls If adding some form of branch locking directly or indirectly (e.g., changing the interface to commitinfo) causes other problems, I'll live without it, add a kludge or move to a tool that supports it. I'm okay with those choices, IF there is a technical reason for CVS to not support branch locking. El-cheap-o branch locking is not hard to hack on with commitinfo. That's about as far as it needs to go I think You say that it solves the wrong problem. Given an example from my day yesterday, a developer was swapping between a couple of workspaces to compare what gets built in a release that is to ship in a few months with one that shipped months back. She accidentally checked in part of a new feature in a back release. Hey, she's human and fifteen minutes later I had the problem fixed. Our organization is large enough that this is a common problem, not because of one or two idiots, but because of the shear number of developers, with differing levels of experience, and number of branches, this problem keeps popping up. I don't see the problem here. You've apparently already got very effective external process controls. No disaster resulted. Your process prevailed. Remember: CVS is not a substitute for management. CVS is not a substitute for developer communication. CVS does not have change control CVS does not have a builtin process model You can build these things atop/around CVS -- i.e. use CVS as a component in a larger system. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 18:16:55 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] why? why can't cvs mv just rename the *,v file? R.T.F.M. PLEASE! -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs exit status
[ On Thursday, October 11, 2001 at 15:48:53 (-0700), Paul Sander wrote: ] Subject: Re: cvs exit status # Overflow occurs here; an exit status less than 258 indicates an overflow. cvs update echo exit status is $? My code would say: cvs update if [ $? -ne 0 ] ; then echo something bad happened, exit status is $? fi exit $? The chances of that failing are one in 127 in the very worst of cases. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Why can't root check in files?
[ On Friday, October 12, 2001 at 10:51:23 (+1000), [EMAIL PROTECTED] wrote: ] Subject: Re: Why can't root check in files? I've looked at it. It is solving a somewhat different problem. It is not only far heavier tool than what I need, it's also more active (li kely to reset permissions to what you had laboriously constructed), and has a much larger learning curve. Hands up how many people are using cfengine on their home system? That's not quite a fair question. The issue isn't which tool you use to drive the configuration of your system using the source files that you will manage with CVS, but rather that you start out with the premise that you do indeed need such a tool in the first place. The choice of which tool you end up using will be guided by requirements entirely unrelated to which change tracking tool you use with the input source files. Greg A. Woods replied to: You need to use some intermediate build process, which when necessary must be run as the superuser, to install your config files into their final resting place. That's not actually true. I *have* a script that runs over a set of /etc-like directories and adds all the plain text files into a CVS archive, and populates the live area with CVS directories and .cvsignore files without altering any of the existing files. Yes, it is true. Your script is part of that tool, though it's incomplete and apparently headed in the wrong direction. You most definitely do not ever want to make /etc a CVS working directory! That's not only dangerous, but is why you're ecountering this problem in the first place. You now need a corresponding program to install the resulting source files into their proper locations in the production system. However the maintenance of the source files and commits of their changes to CVS must be done by a real user-id, i.e. some user-id that represents exactly one real-world person. You can't guarantee this, ever. Excuse me? Accountability is a fundamental cornerstone of all computer systems security. You have no real security without it. Everything you said after that sentence is further down the road of your confusion and isn't worth arguing point by point. The process I've used successfully in the past was to build a mechanism much like cfengine (but more primitive), and to create a CVS module writable only by the wheel group. This module was populated with configuration files for the target system(s). Users then checked out this module, as themselves into a private and protected working directly, and from there they could commit changes to the files in it. To install the resulting files into production they would 'su' and then run make install in their working directories. One of the first commands run by the makefile was a cvs -nq update check to ensure that the files they were installing were all committed (and up-to-date). Other simple consistency checks were also done on some of the files, such as ensuring the old copy was still identical to the revision noted in its RCS $Id line (i.e. to ensure no uncommitted changes would be clobbered). Accountability here is maintained in several ways, including through the CVS repository and through the 'su' logs. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? If your question really is: Is anyone making locking a mainstream feature of CVS? Then I believe the answer is no. shame ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
No link to any files produces anything. One cannot download a patch that is not there. [EMAIL PROTECTED] wrote: The patches are there for anyone to use. Last I heard, all that's stopping them from being included with the standard distribution are the lack of test and doc patches. You're welcome to work on them. Welcome to the world of open source. Noel The RCVS part on source forge seems to be dead. Is anyone really developing locking for CVS? [EMAIL PROTECTED] wrote: The most you could hope for in CVS is to install a patch that allows advisory locks -- reserved locks are counter to the purpose of CVS. You can find a version of the patch (I think against cvs-1.11.1) at SourceForge under project RCVS. Once the patch is installed, tell the users that they must have cvs edit -c and cvs ci -c in their ~/.cvsrc files. Be sure to turn on notification as well. The process they should follow is: 1. When intending to modify a file for checkin, cvs edit the file. 2. If the files are being edited by others, contact the other parties to minimize the chances of conflicts. 3. If the chances of conflicts is minimal or the others cannot be contacted, cvs edit -f the files. 4. If one receives notification about an as-yet-unknown edit, contact the editor to help minimize the chances of conflicts. Noel Hello all, Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? If there is any info., please email to [EMAIL PROTECTED] Many thanks in advance Andrew ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs edit -c command
Sure, if you have the link already. This one produces nothing: http://sourceforge.net/project/showfiles.php?group_id=4680 This one produces cvs commands that do not work (no log in allowed): http://sourceforge.net/cvs/?group_id=4680 The ftp link is to a directory that does not exist. I stand by what I wrote. This project is unreachable and DOA. [EMAIL PROTECTED] wrote: I don't know what you're talking about. I was able to get the reservations patch at http://sourceforge.net/tracker/download.php?group_id=4680atid=304680file_id=6141aid=422725 Noel There are no files to download in this project. Looks DOA. [EMAIL PROTECTED] wrote: > The patch is available at SourceForge under project RCVS. > > The gist of the patch is: > 1. "cvs edit -c" will abort the edit if another is editing the files. > 2. "cvs edit -f" will force the edit. > 3. "cvs ci -c" will abort the checkin if a valid edit does not exist on > the files. > > Noel > > Does anyone know where I can find some info on this command and arguments. > I can't seem to find it > Thanks > > Curt Stanton > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > > This communication is for informational purposes only. It is not intended as > an offer or solicitation for the purchase or sale of any financial instrument > or as an official confirmation of any transaction. All market prices, data > and other information are not warranted as to completeness or accuracy and > are subject to change without notice. Any comments or statements made herein > do not necessarily reflect those of J.P. Morgan Chase Co., its > subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates.
Re: [kfogel@collab.net: Re: rename in cvs]
[ On , October 11, 2001 at 17:31:05 (-0400), Sam Steingold wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Why can't I see the log for all of them in one command? Because that's not the way CVS works. Consider a versioning file system which has a native idea of file version. I can rename file FOO;latest to BAR;latest, keeping the older versions of FOO named FOO;1, FOO;2 c. - this corresponds to the CVS method (rm/add). But I also can rename _all_ version of FOO to BAR. This _is_ a reasonable thing to do. Why can't I do it with CVS? Because that's not the way CVS works. Please note that the answers like this is not how CVS manages change! are not very convincing, because the natural retort is then maybe CVS manages change incorrectly? Well, maybe you should try a little harder to learn how CVS works and find out what it's really doing internally. Even the manual discusses most of the issues regarding renames quite clearly and accurately. Please tell us _why_ the request for the CVS command mv, which would rename the *,v file and replace the CVS/Entries entry is unreasonable. (Oh yeah, CVSROOT/history should also be suitably modified and a record of the renaming to allow for undoing it should also be added. But is these are too hard to implement, forget it and stick with a simple mv FOO,v BAR,v). CVS cannot do what you want it to do. The reasons why not have been discussed almost infinitely. Some new tool might someday be able to do this, and several commercial tools claim to be able to already. And while I am talking about undoing, why can't a revision be removed from the CVS? just like I can remove a revision in a versioning file system, I should be able to remove a revision from the CVS. You can, but you shouldn't. The proper way to undo, or revert, a change in any change tracking system is to apply the change as a reverse patch, thus removing the change from the new file, and then commit that as a new change again, noting in the commit message which delta you've reverted. Don't get me wrong. CVS is a great tool. Let's make it even better! To make CVS do what you want will require changes so extensive and ground shaking that the result will no longer interoperate with a normal CVS repository. The transformation will be complete and it will create a new tool. Word is people are already working on such a thing -- whether they'll succeed or not is yet to be seen. Note that Perforce and BitKeeper already claim to have rename support, and BitKeeper claims to have the best rename support of all. Howeve even in BitKeeper Conceptually, a rename is seen as a deletion of one file and a creation of another file. So, there you have it. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
If your question really is: Is anyone making locking a mainstream feature of CVS? Then I believe the answer is no. shame I think getting real reserved locks into CVS is impossible without chainging CVS so much as to make it not CVS anymore. Of course, you're welcome to try. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
[ On Friday, October 12, 2001 at 02:17:41 (GMT), Bryon Lape wrote: ] Subject: Re: CVS - setup reserved checkout Paul Sander wrote: If your question really is: Is anyone making locking a mainstream feature of CVS? Then I believe the answer is no. shame Repeat after me: CVS == the _Concurrent_ Versions System Read the sub-title of Berliner's paper (included in the source). Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Anyone have VSS2CVS?
Alex, Try www.laine.org:8080/cvs/vss2cvs/ I think his ISP is blocking http inbounds on port 80. -Greg Alex Jacques wrote: The site for vss2cvs (http://www.laine.org/cvs/vss2cvs/) is down, and judging by a previous message to this mailing list (http://mail.gnu.org/pipermail/info-cvs/2001-September/019557.html) has been since at least 4 Sep 2001. Does anyone have a copy of this script that they could email, or better yet, post somewhere? Thanks. BTW, I know there is an old version of it at http://alexm.here.ru/cvs-nserver/download/contrib/vss-to-cvs/jnairn/ but this is an old unenhanced version. ___ 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 - setup reserved checkout
There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to lock CVS for check-in
Absolutely - I would be relieved if commitinfo scripts get the branch information as well. But I am reluctant to go do it myself because of my unfamiliarity with CVS code and lack of time to gain some familiarity with it. Though there have been patches floating around which achieved the same, for some reason or the other they have not been integrated into the CVS codebase. I could have built a patched CVS binary and use it, but the shop where I work, the CVS server is controlled by the IT department (since it is shared among a whole bunch of groups) and they are extremely reluctant to accept such patches. Thanks Shubho -Original Message- From: Greg A. Woods [EMAIL PROTECTED] To: CVS-II Discussion Mailing List [EMAIL PROTECTED] Date: Thursday, October 11, 2001 10:38 PM Subject: Re: How to lock CVS for check-in [ On Thursday, October 11, 2001 at 11:11:21 (+0530), Shubhabrata Sengupta wrote: ] Subject: Re: How to lock CVS for check-in At least in pserver access it is and I think it is also available in for local repository access as well. I am not sure about :ext: access though. I agree that its contents and its structure is entirely internal to CVS and may change without notice from one CVS release to another. I do not write anything into CVS/Entries at all - I use it to read the branch name of the file that is being committed. So that way there is very little danger of corrupting that file. Of course I make assumptions about the structure of the file and that may change from one CVS release to another - I am ready to change the regex I use to grep the branch name when that happens. The advantages I get from controlling access to branches through commitinfo script outweighs the risk in my case. Then is it not better to improve the commitinfo interface so that access to the raw CVS/Entries file is not necessary? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
*** REPLY SEPARATOR *** On 11/10/2001 at 23:03 [EMAIL PROTECTED] wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. I understand it, there aren't any. - Tired of NOT having your money backed by GOLD!?!? https://www.e-gold.com/newacct/newaccount.asp?cid=117395 Why settle for the low interest rates of banks? Why gamble in the stock market? http://www.emutualfun.org/m.cfm?mid=UPD886 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Wo? Ich kann nicht es gefunden. Paul Sander wrote: There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Greg A. Woods wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. The benefits add up to zero. Now, if it did method locking, that would be helpful, protective AND productive. Without some sort of locking, having developers waste time with doing merging by hand is counterproductive. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to lock CVS for check-in
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 10, 2001 10:11 PM [ On Thursday, October 11, 2001 at 08:24:11 (+0530), Shubhabrata Sengupta wrote: ] Wondering why this enhancement is needed in the commitinfo interface when you can always get the branch information out of the CVS/Entries file which is always available to the commitinfo script. I'm not sure the CVS/Entries file is always available, and in any case accessing it directly is a very very very bad hack. Its cvs -n stat filename works very well to get this kind of info from a commitinfo script. You get it from the CVS/Entries file through a cvs command. Jerry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
In article [EMAIL PROTECTED], Bryon Lape wrote: Greg A. Woods wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. The benefits add up to zero. Now, if it did method locking, that would be helpful, protective AND productive. Without some sort of locking, having developers waste time with doing merging by hand is counterproductive. Nobody who actually has experience with parallel development could possibly say something so utterly clueless. Try it first, then talk. CVS doesn't require hand merging. When you perform a cvs update operation, then new changes in the repository are automatically incorporated into your working copy. Only when a conflict arises do you have to do resolution by hand. Conflicts tend to occur rarely, and are usually very easy to resolve. You will find that it takes less time to resolve the odd conflict than to wait for someone's lock to be released. So overall, productivity is boosted rather than reduced. Is there any hard, statistical data to back this up? No. But find someone who has done parallel development with reasonable tools, and who will testify that it was difficult or that it reduced productivity. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Making a file writeable
In a sane and normal source control system, Do you mean a we can't figure out how to implement parallel development so we'll put a straightjacket on our customers and convince them that it's superior source control system? files stay read only until you check them out. Bad Bad Bad Bad Bad Oh how many times I've wanted to smack somebody up side the head for this. This is OK only in some development environments. CVS seems to be neither and lets people change files at will. This is quite bad and counter productive. Have you attempted to understand the theory of operation? I've spent a weekend giving myself a crash course in CVS. Yes, it's different than, say Visual Source Safe, but it's neither wrong, bad, nor counterproductive. I rather like it. Sadly it's freaking another developer out in a big way -- and I have to deal with him. CVS requires a mental adjustment to client-oriented parallel development. The straightjacket is off. I guess it's like freedom. Freedom scares the living daylights out of people conditioned to living under tight controls. -- Practice makes permanent. Perfect practice makes perfect. - Seville ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Module directory nameing....
now if I can just add locking to CVS Try understanding client-oriented parallel development. It will cause less heartburn, reduce your stress, and reduce the rate of hair loss. Locking exists as an administrative option. However... I would seriously discourage trying to make CVS behave like Visual Source Safe. Much unhappiness. CVS is a tool designed to do a task well. Don't try to force it to be a different tool. Happiness = False. -- The program isn't debugged until the last user is dead. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Ich funde es bei http://sourceforge.net/tracker/index.php?func=detailaid=422733group_id=4680atid=304680 --- Forwarded mail from [EMAIL PROTECTED] Wo? Ich kann nicht es gefunden. Paul Sander wrote: There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? --- End of forwarded message from [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from Greg Woods: [ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: * 'cvs log BAR' does not list changes in file FOO Of course not You do not want it to! That would be illogical. That is false. Just because the tool doesn't do something doesn't mean we don't *want* it or that it is illogical. Some version control tools can handle renames. The actual object being version is stored anonymously, and a path name is just another versioned property of that object. Let me repeat: You DO NOT want or need to have cvs log BAR list changes in the file FOO. To want that is illogical. It is unnecessary! You do, if the version history of FOO is part of the history of BAR, having become that way by way of a reorganization of the project. Unless and until you understand this you will not understand how CVS manages change and how filenames are used within CVS. Until you understand why the design of CVS is broken, you will never understand why this is a reasonable expectation. Go away and figure it out. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
