Re: CVS diff and unknown files.
Greg A. Woods [EMAIL PROTECTED] writes: [ On Wednesday, February 2, 2005 at 15:33:28 (-0800), Mark D. Baushke wrote: ] Subject: Re: CVS diff and unknown files. Greg A. Woods [EMAIL PROTECTED] writes: Yes -- we are in almost full agreement, but it cannot use '-n'. (no commitinfo scripts are run with '-n' and I don't think they should be or ever need to be) I believe this statement does not reflect the current state of cvs. You're right of course. cvs -n commit does contact the server (as it should of course) and it does run any commitinfo scripts. I was no doubt confusing commit with add when I made that claim. But this just makes it even easier to answer Paul's idea for a server based technical control over file naming. He simply needs to write a commitinfo script that checks new names against his file naming policies and then instruct his users to cvs -n commit newfile whenever they want to check their new filenames against the server's policies. They don't have to commit empty files and they don't have to In fact his new customized CVS client could even combine these operations, and any wrapper/front-end program could trivially do so as well. Greg, I tried hard indeed to explain exactly this to Paul. It's hopeless. He doesn't buy the idea, -- he just can't forget his favorite add-time triggers. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
[ On Wednesday, February 2, 2005 at 12:08:54 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. So while you believe that add-time hooks are folly, there's another half of the community that thinks they're very useful. Sergei, in the SCM world, there are many issues in which half of the community thinks one way, the other half thinks the opposite. Note that _I_ don't really have a set opinion either way w.r.t. whether it's a good thing to be able to enforce policies on new files. I just know that cvs add is not ever going to be the right place to implement technical controls for such policies. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
[ On Wednesday, February 2, 2005 at 15:33:28 (-0800), Mark D. Baushke wrote: ] Subject: Re: CVS diff and unknown files. Greg A. Woods [EMAIL PROTECTED] writes: Yes -- we are in almost full agreement, but it cannot use '-n'. (no commitinfo scripts are run with '-n' and I don't think they should be or ever need to be) I believe this statement does not reflect the current state of cvs. You're right of course. cvs -n commit does contact the server (as it should of course) and it does run any commitinfo scripts. I was no doubt confusing commit with add when I made that claim. But this just makes it even easier to answer Paul's idea for a server based technical control over file naming. He simply needs to write a commitinfo script that checks new names against his file naming policies and then instruct his users to cvs -n commit newfile whenever they want to check their new filenames against the server's policies. They don't have to commit empty files and they don't have to In fact his new customized CVS client could even combine these operations, and any wrapper/front-end program could trivially do so as well. In addition, the current 'cvs' requires that you actually contact the server to cause a new directory to be added. Well, yes, but that's clearly a bug -- ans something that we have all wanted to fix for a very very VERY long time now. It is a bug that should have been fixed when the client and server parts of CVS were first separated. There never was any fundamental requirement for creating a new empty directory in the repository -- it was the way it was done internally before CVS was ever split into client and server, it's still just a cheap, poor, hack that only slightly simplifies one minor aspect of the internal implementation. I think use of a simple stack structure would easily avoid this nasty hack, though fixing the code while the code still implements the stand-alone unified non-C/S variant would still be a bit complicated, but it wouldn't be hard to re-implement the non-C/S variant as a client and server that communicate through a pair of local pipes (that might even allow for clean-up of a lot of code!). Another reason it's a bug is that most people I know (myself included :-) feel that making any change to the repository that doesn't go through cvs commit is just plain wrong, never mind that cvs add can also be used as a kind of denial-of-service attack against one's colleagues, and even when SSH is used the normal auditing trail for making changes to the repository is not followed and no record is even made in the history file (if one is being used), so significant forensic work would be needed to identify the culprit, especially on a busy server. In fact these reasons were all part of the impetus behind my re-design of cvs add in the first place. (along with the desire to replace cvs import once and for all as the way to create a new non-vendor module from an existing set of project files, and of course with the goal of making cvs add a true and complete match for cvs rm in its design) -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Feb 1, 2005, at 8:16 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 31, 2005, at 9:30 AM, [EMAIL PROTECTED] wrote: That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are clearly not ready to check at add time. Well, if I understand correctly, your intentionally want to have weaker checks at add-time than at commit-time. Instead, you can do it in the commit-time trigger by skipping some of the tests if the file in question is new one. Oh, so what you're saying is that rather than making CVS differentiate between the two sets of triggers, you want the commitinfo script to do it instead. I suppose that's doable. Exactly! I took too much time to explain this. Should be either my or your fault (or both). But I'll counter with this: Why not combine commitinfo, loginfo, and taginfo the same way? My argument is that add-time triggers differ from commitinfo triggers in the same way that commitinfo triggers differ from those others: They run at different times for different purposes. All the triggers you've mentioned have no common tasks to do. On the other hand, add-time checks you have in mind are subset of commit-time checks you have in mind. The subset is easily achieved by bypassing some of checks. Okay so you understand why it's a bad idea to overload too much functionality. I argue that combining add-time and commit-time triggers is also overloading things too much. There's the established commit-time feature that is being modified so that it now runs twice rather than once. If this were indeed done, then thousands of existing CVS admins are inconvenienced because they must rewrite their existing commitinfo triggers to bypass their current operation at add-time, and plus both the CVS authors and the administrators must work through a change of interface in an existing feature. If you examine the implementation, you'd realize that CVS implements its trigger support pretty much in a generic fashion, basically invoking a function call with different parameters depending on the trigger. So there's really no invention going on when adding a new trigger. And it turns out that overloading an existing one is demonstrably harmful. I would have no objection to add-time-script if there were a separate server operation called add-file-to-the-working-copy, or check-if-file-name-is-ok-for-repository, but AFAIK there is currently no such operations. I consider inventing new server operation just to implement some policy that you have in mind and that could be implemented using existing functionality anyway to be an overkill, sorry. If you go back and read Mark's postings, he mentions that my proposal requires no changes to the client/server protocol, so it's really not inventing a new server operation in a very real sense. It changes the behavior of the server, but if at add-time you invoke the option to avoid contacting the server, then why do you care? You need to get out of the server. The server's not the one we're trying to make happy here. It's the user that matters, and the tools must bend to the users, not the other way around. From an implementation standpoint, there's no difference between the triggers, other than the conditions in which they fire and the files in which they're configured. Thus the argument you make in the above paragraph simply makes no sense. It's you who needs to get out of the server, not me. You propose server changes, not me. If the functionality has nothing to do with the server, then get out of the server indeed. Yes, you do propose server changes: You propose invoking an existing trigger in a second place. I argue that implementing a second one performs the same function that you propose, but in a cleaner way that preserves existing practice. If I do in fact understand you to be recommending that commitinfo be used at add time, then I must disagree. Triggers used at commit time to check the content of files (like Greg's RCS Id trigger, for example) are not appropriate to use at add time. Things like checking that the user has the right to add a file, or checking that the name of the file complies with policy, are legitimate to check at add time. They can also be checked at commit time, and the current proposal does that because the add-time triggers are optional. So the only thing you need to know in the commitinfo is what user is trying to do and decide what checks are required based on this information. If commitinfo currently doesn't have all the required information, maybe it's better to fix it instead of inventing yet another hack in the form of add-time triggers? What you're really proposing is an alternative implementation for add-time triggers. Think about it. It's how it looks from your point of view. From my point of view I propose alternative implementation of the functionality you need without inventing anything new,
Re: Triggers (was Re: CVS diff and unknown files.)
On Feb 1, 2005, at 12:03 PM, [EMAIL PROTECTED] wrote: [ On Saturday, January 29, 2005 at 15:22:34 (-0800), Paul Sander wrote: ] Subject: Re: Triggers (was Re: CVS diff and unknown files.) You don't seem to understand the fact that cvs add and cvs rm are supposed to be exactly the same as vi or any other file modification tool (except they operate on the whole file and all its content at once). What I understand is that they are that way, and that they have always been that way. I might even accept the argument that they're supposed to be that way. What I will not accept is that they *must* be that way, and I argue that there is value if they are changed. You don't seem to understand that your insanely powerful drive to have policy controls over everything is quite contrary to the very design goals of CVS overall. I do not have an insanely powerful drive to have policy controls over everything. I have strong desire to have some control over things that meet one of these two criteria: - By consensus, they offer significant advantage in time and expense. - They are demonstrably harmful, i.e. have been used to cause significant harm in the past. CVS is _NOT_ a complete SCM solution and it's not supposed to try to be one either. Adding triggers won't make it a complete SCM solution. But they would make it easier to integrate it with other tools to create one. That is what I'm after. Wrappers are enablers, not enforcers. By their nature, they cannot be enforcers. Yes, they can be. You need to think a little more outside the box you've built around your ideas. Okay suggest a way to do it that's easier than adding a trigger to CVS. Triggers, on the other hand, are enforcers. Actually that's one thing they cannot be -- at least not at any hard technical controls level. CVS is not a security tool. I'm not asking CVS to be a security tool. I'm asking for more places for it to say no when users attempt things that are not permitted by the project. CVS is not about enforcing policy. CVS is not a complete SCM solution. Obviously not, that's why we're having this argument. CVS is a very simple file versioning tool that is designed to keep as much out of the way of the user as is possible and only do exactly what the user wants, and to do it only when the user wants it done, and to only try to do a very select set of operations on a very select set of object types. NOTHING more. Fine. Give me the hooks I need and I'll make it into what I need it to be. Tell me something. If this were true, why does your commitinfo check for valid RCS ID's? Why don't you periodically run a script to check your sources for them? Because it's easier and infinitely more efficient to have CVS run that script exactly once when it's needed on exactly the files it needs to run it on and never any other time and never on any other files. Yep, that's what I want, too. I just have different actions that I want to perform. Here's another horror story. On another project, we're using a version control system that has a command that does what cvs rm does, but with an instant commit. It also has an option to perform a recursive descent. Why is that a horror story? The whole point of versioning systems is that you can undo your changes. After all you didn't say that the command did what rm -rf /* does when root runs it -- i.e. it didn't make a permanent, irreversible, change that affected everyone. True, but it did make a temporary, reversible change that affected everyone. And it took hundreds of man-hours to recover. TWICE!!! This is not acceptable. The CM guy for that project was concerned about such capability in the hands of the end users, and raised the issue with management about whether or not to make it an admin function. Than he is, or was at that time, a paranoid idiot who doesn't, or didn't, understand the tools and their utility. It took them a day to restore visibility of all of the files, and a week to redo the legitimate deletions that had accumulated. Clearly that tool wasn't very well designed and implemented to do even the very most basic job of change management. Really? In CVS, the corresponding actions are to run cvs add on every file found in the attic, review the tree, and run cvs rm for the files that had been legitimately removed prior to the hiccup. Had we used CVS, we would have been in exactly the same boat. If we'd had the ability to limit the effect of the removal command, we could have either forced the user to rethink what they were doing or at least reduce the amount of work required for recovery. That would have been good. There are many ways we could have limited the effects of the removal that would have not gotten in the user's way, at least to a lesser degree than the amount of work required to recover. We could have: - Disabled the recursive descent option for end users (i.e. have an admin do it). - Limited the depth of the removal. - Limited
Re: CVS diff and unknown files.
Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 31, 2005 at 20:30:21 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. Don't you wish to even try to understand the suggestion? The suggestion is: invoke *the same triggers* both at 'cvs add' and 'cvs commit' time, -- there is no need for separate triggers. No, using the same scripting hook at both add and commit times would be bad, VERY bad. Sure. But I didn't in fact suggest it. I in fact argue in favor of absence of add-time hooks on the server at all. Let me try to explain, as the exact meaning of the suggestion has been somehow lost in the endless discussion with Paul. What do we exactly mean by add-time here? The time when cvs add client command is invoked, or the time when new file is to be committed to the repository using cvs commit? If the latter, that is not the topic of this discussion. If the former, then server should not care/know about cvs add at all, so there is no such thing as add-to-working-copy time from the point of view of server, so there could be no server hooks invoked at this non-existing time, so these non-existing hooks can be neither the same nor different from commit-time hooks. In other words, I believe there should be no cvs add server command at all. What I actually meant in the phrase you've taken out of contents and commented against is: iff somebody decides he needs to perform some checks on the server whenever user adds files to his working copy, he can arrange to invoke cvs -n commit after every cvs add (or as [optional] part of cvs add). This effectively makes *virtual* add-time hooks equal to commit-time hooks without any server-side add-time hooks. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Feb 2, 2005, at 5:02 AM, [EMAIL PROTECTED] wrote: Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 31, 2005 at 20:30:21 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. Don't you wish to even try to understand the suggestion? The suggestion is: invoke *the same triggers* both at 'cvs add' and 'cvs commit' time, -- there is no need for separate triggers. No, using the same scripting hook at both add and commit times would be bad, VERY bad. Sure. But I didn't in fact suggest it. I in fact argue in favor of absence of add-time hooks on the server at all. Let me try to explain, as the exact meaning of the suggestion has been somehow lost in the endless discussion with Paul. What do we exactly mean by add-time here? The time when cvs add client command is invoked, or the time when new file is to be committed to the repository using cvs commit? I think we agree that add-time is the moment that the user invokes the cvs add command. If the latter, that is not the topic of this discussion. If the former, then server should not care/know about cvs add at all, so there is no such thing as add-to-working-copy time from the point of view of server, so there could be no server hooks invoked at this non-existing time, so these non-existing hooks can be neither the same nor different from commit-time hooks. In other words, I believe there should be no cvs add server command at all. My argument has always been that, for certain policies that do not involve evaluating the content of a file (like enforcement of naming conventions) that there is value to having an add-time check. The reason for this is that if certain classes of early actions are botched, it's better to find out sooner than later, because doing so can save the user from a lot of lost work. So while you believe that add-time hooks are folly, there's another half of the community that thinks they're very useful. Sergei, in the SCM world, there are many issues in which half of the community thinks one way, the other half thinks the opposite. This is apparently one of those issues, at least with CVS. There is no winning the argument on either side. All that can be done is to build a solution that satisfies one side without inconveniencing the other side too much. I believe that my proposal does exactly that. To recap: - Create an add-time trigger mechanism that - Has an interface identical to the existing *info files - Registers the add-time triggers in a new file, perhaps named addinfo - On the client side and selected by the user, perform one of the following actions when the user invokes the cvs add command - Record the new file in the Entries file without contacting the server - Contact the server to run the addinfo trigger, recording the new file in the Entries file if the trigger complete successfully - Run the addinfo trigger prior to any commitinfo trigger when the user invokes the cvs commit command The reasons I believe this proposal satisfies all requirements are: - Using addinfo triggers is a decision of individual projects. - Users are not required to change their working habits. - Users and projects that need add-time triggers get them. - For CVS administrators, this is fully backward compatible. - For CVS users, a new option to cvs add appears which either: - contacts the server by default but is defeated forever in one action or on the command line - does not contact the server by default but is enabled forever in one action or on the command line In other words, it has zero impact on those who don't want or need it, but it's available to those who do. What I actually meant in the phrase you've taken out of contents and commented against is: iff somebody decides he needs to perform some checks on the server whenever user adds files to his working copy, he can arrange to invoke cvs -n commit after every cvs add (or as [optional] part of cvs add). This effectively makes *virtual* add-time hooks equal to commit-time hooks without any server-side add-time hooks. The problem is that if you reuse the commit-time hooks in this way, you are overloading that capability in a way that I (and apparently Greg) believe is not appropriate. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
[ On Wednesday, February 2, 2005 at 01:58:31 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. I argue that combining add-time and commit-time triggers is also overloading things too much. You don't seem to understand yet that an add or rm is NO different than any other change. Please refer to my reply to Sergei and try to learn this simple fact. Because in my experience, users don't heed warnings. Whenever I need to get their attention, I need to hit them over head with a failure. Exactly. People learn (best) from their mistakes. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
[ On , February 2, 2005 at 16:02:12 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. What do we exactly mean by add-time here? The time when cvs add client command is invoked, or the time when new file is to be committed to the repository using cvs commit? I've always meant the former -- i.e. add-time == 'cvs add' invocation. To me the latter is a non-existant, and completely bogus, concept that's best squashed and never thought of again. If the former, then server should not care/know about cvs add at all, so there is no such thing as add-to-working-copy time from the point of view of server, so there could be no server hooks invoked at this non-existing time, so these non-existing hooks can be neither the same nor different from commit-time hooks. In other words, I believe there should be no cvs add server command at all. Hurray! Yes, exactly! cvs add (and cvs rm) are no different than using vi or emacs, etc. to change files in the working directory. The only difference being that the user needs to do something special to record the presence of a to-be-managed (or or lack of presence of a formerly managed) file in the working directory's CVS administrative state files since normal local filesystem operations do not, and cannot, be noticed after-the-fact by CVS. What I actually meant in the phrase you've taken out of contents and commented against is: iff somebody decides he needs to perform some checks on the server whenever user adds files to his working copy, he can arrange to invoke cvs -n commit after every cvs add (or as [optional] part of cvs add). This effectively makes *virtual* add-time hooks equal to commit-time hooks without any server-side add-time hooks. Yes -- we are in almost full agreement, but it cannot use '-n'. (no commitinfo scripts are run with '-n' and I don't think they should be or ever need to be) Also it's best not to ever even use the phrase add-time hooks, virtual or otherwise. A commit of an added file is no different than any other commit except that the file whole content now appears, not just some changes to the file (or alternately every line of an empty file is changed and replaced with all the lines of the new file). It's literally equivalent to diff /dev/null newfile.c. Commitinfo scripting hooks can (or at least they should be able to) check to see if the whole file is appearing, or there are just changes to an existing file, and one or more of those scripts can make decisions based on any criteria available about the new file at commit time. A commit of a new file is just a change of all the lines in the file. One could even consider, logically speaking, that the file was dead (and effectively in the Attic) and now it's being resurrected. In fact that's _exactly_ what happens when a file is removed committed, and then added and committed again. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg A. Woods [EMAIL PROTECTED] writes: Yes -- we are in almost full agreement, but it cannot use '-n'. (no commitinfo scripts are run with '-n' and I don't think they should be or ever need to be) I believe this statement does not reflect the current state of cvs. (I may have missed something where you wanted to change the existing behavior and are using that as the basis for your statement.) The commitinfo triggers are run even when the -n switch is used. Try it for yourself with a stock version of cvs 1.11.x or cvs 1.12.x. cvs -d `uname -n`:/tmp/my-repos init cvs -d `uname -n`:/tmp/my-repos co CVSROOT cd CVSROOT echo 'DEFAULT echo commitinfo trigger running:' commitinfo cvs commit -m new-default commitinfo touch foo cvs add foo cvs -n ci -madd-foo foo You should get the output: commitinfo trigger running: /tmp/my-repos/CVSROOT foo In addition, the current 'cvs' requires that you actually contact the server to cause a new directory to be added. If I just do a simulated call that modifies a 'mkdir newdir cvs add newdir' to these steps: mkdir newdir newdir/CVS echo 'D/newdir' CVS/Entries cp CVS/Root newdir/CVS/Root echo `cat CVS/Repository`/newdir newdir/CVS/Repository touch newdir/CVS/Entries then subsequent 'cvs update' operations will have problems such as this: % cvs up cvs update: Updating . A foo cvs update: Updating newdir cvs update: cannot open directory /tmp/my-repos/CVSROOT/newdir: No such file or directory cvs update: skipping directory newdir % which will require that 'newdir' be created via a 'cvs add' conversation with the server eventually. As a reminder, no matter how much folks believe things should be different: - currently the 'cvs add' command talks to the server - on the occasion of a 'directory' being added, the directory is created in the repository if a lock may be created and valid permissions exist to create it. Next, the loginfo trigger is run. Any changes to cvs to alter the behavior of 'cvs add' should allow for new clients to talk to old servers and for old clients to talk to new servers in addition to new clients talking with new servers. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCAWNI3x41pRYZE/gRAgcDAJ9PFZp5BsFd+DbwyZb9sggYIn/ltgCgtbRn 0cXV85BlYqwfwNaPd3dbF1Y= =RieR -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Jan 30, 2005, at 2:18 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Todd Denniston [EMAIL PROTECTED] writes: If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer is through appropriate error message, as usual. Please notice that with separate add-to-working-copy-time triggers the situation at commit time is exactly the same as those triggers must be run at commit time anyway. What's an answer to your question in this case? There is a certain amount beauty in the simplicity in keeping the status quo, which works. :) Unfortunately, it doesn't work, sorry -- that's why I've initiated this thread in the first place. Huh? You know what status quo means, right? It means the way things are. Sure. And the way things are aka status quo doesn't work for me, -- that's the problem. You seem to be arguing both ways. I don't think so. I even can't guess what are these ways you have in your mind. Would you post a message stating your point of view, completely, please? Thanks! I need a way to generate 'cvs diff' against read-only repository. To achieve this it's enough to fix 'cvs add' so that it either doesn't contact the repository at all, or just doesn't require write permission to the repository to succeed. As a response to the question, I've got a reference to the discussion about new 'cvs add' implementation, where you, Paul, argue in favor of new implementation of 'cvs add' to contact the repository to run some new scripts you called add-time triggers. I then tried to tell that I'm yet another person here who is against such a thing and tried to suggest another way of achieving your actual goal, -- checking something against repository at add-to-working-copy time using existing commit-time triggers. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Feb 1, 2005, at 2:51 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: Would you post a message stating your point of view, completely, please? Thanks! I need a way to generate 'cvs diff' against read-only repository. To achieve this it's enough to fix 'cvs add' so that it either doesn't contact the repository at all, or just doesn't require write permission to the repository to succeed. As a response to the question, I've got a reference to the discussion about new 'cvs add' implementation, where you, Paul, argue in favor of new implementation of 'cvs add' to contact the repository to run some new scripts you called add-time triggers. I then tried to tell that I'm yet another person here who is against such a thing and tried to suggest another way of achieving your actual goal, -- checking something against repository at add-to-working-copy time using existing commit-time triggers. There are two proposals on the table. The first is Greg Woods' proposal to make cvs add be a purely local operation. The second is mine, which implements add-time triggers that require calling the server but in a way that the user can opt out of them when invoking cvs add. Does that meet your need? -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Feb 1, 2005, at 2:51 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: Would you post a message stating your point of view, completely, please? Thanks! I need a way to generate 'cvs diff' against read-only repository. To achieve this it's enough to fix 'cvs add' so that it either doesn't contact the repository at all, or just doesn't require write permission to the repository to succeed. As a response to the question, I've got a reference to the discussion about new 'cvs add' implementation, where you, Paul, argue in favor of new implementation of 'cvs add' to contact the repository to run some new scripts you called add-time triggers. I then tried to tell that I'm yet another person here who is against such a thing and tried to suggest another way of achieving your actual goal, -- checking something against repository at add-to-working-copy time using existing commit-time triggers. There are two proposals on the table. The first is Greg Woods' proposal to make cvs add be a purely local operation. The second is mine, which implements add-time triggers that require calling the server but in a way that the user can opt out of them when invoking cvs add. Does that meet your need? I like Greg's proposal and explicitly stated it first time I touched this issue after reading relevant thread I've been pointed at. I don't like your proposal and explicitly stated it first time I touched the issue. Though your proposal is in fact orthogonal to my original concern with 'cvs diff' and thus I don't care that much about it. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Jan 31, 2005, at 9:30 AM, [EMAIL PROTECTED] wrote: [...] Don't you wish to even try to understand the suggestion? The suggestion is: invoke *the same triggers* both at 'cvs add' and 'cvs commit' time, -- there is no need for separate triggers. I understand it perfectly. What you don't seem to understand is that the set of possible actions taken at add time is different from those actions taken at commit time. Triggers and actions taken aren't the same thing. I fail to see why the same trigger can't take different actions. These two sets cannot simply be combined and run at both times. You already said that add-time checks is subset of commit-time checks. Just bypass some tests if the triggers are invoked at add-time. That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are clearly not ready to check at add time. Well, if I understand correctly, your intentionally want to have weaker checks at add-time than at commit-time. Instead, you can do it in the commit-time trigger by skipping some of the tests if the file in question is new one. Oh, so what you're saying is that rather than making CVS differentiate between the two sets of triggers, you want the commitinfo script to do it instead. I suppose that's doable. Exactly! I took too much time to explain this. Should be either my or your fault (or both). But I'll counter with this: Why not combine commitinfo, loginfo, and taginfo the same way? My argument is that add-time triggers differ from commitinfo triggers in the same way that commitinfo triggers differ from those others: They run at different times for different purposes. All the triggers you've mentioned have no common tasks to do. On the other hand, add-time checks you have in mind are subset of commit-time checks you have in mind. The subset is easily achieved by bypassing some of checks. I would have no objection to add-time-script if there were a separate server operation called add-file-to-the-working-copy, or check-if-file-name-is-ok-for-repository, but AFAIK there is currently no such operations. I consider inventing new server operation just to implement some policy that you have in mind and that could be implemented using existing functionality anyway to be an overkill, sorry. What's new is that we can cause cvs add to fail under certain conditions that we know in advance will cause commitinfo to refuse a file. To make sure that the condition is checked, we do it a second time before commitinfo, because some users insist on defeating it the first time. What functionality is lacking? cvs -n ci allows you to do it. All you require is cvs add to *enforce* the checks. I have two levels of objection here: 1. Enforcement by cvs add of the checks doesn't require introduction of separate add triggers as usual commit triggers could do the job as well. My argument is that it does not in fact do the job as well. I've given a number of reasons why in earlier messages. No, you didn't. Or at least I somehow missed them. The fact that currently CVS doesn't invoke any triggers at add-time has nothing to do with my objection. The question is what is so different about add-time triggers from the point of view of *server* so that it's not enough to just invoke commit-time scripts at the add-time? You need to get out of the server. The server's not the one we're trying to make happy here. It's the user that matters, and the tools must bend to the users, not the other way around. From an implementation standpoint, there's no difference between the triggers, other than the conditions in which they fire and the files in which they're configured. Thus the argument you make in the above paragraph simply makes no sense. It's you who needs to get out of the server, not me. You propose server changes, not me. If the functionality has nothing to do with the server, then get out of the server indeed. Triggers certainly don't have full control over the user's workspace. But they can decide what interactions with the server are acceptable to the server's admin. That is why they're good as enforcers. That's why they are good as enforcers of things that happen on the server. They (fortunately) have absolutely no control over the user's workspace. Wrappers don't have that capability, because they have no way to be final authority to decide what is acceptable to the server. Yes, wrappers don't have that capability, enforcing things on the server, but unlike server-side triggers, they do have capabilities (to the level your favorite OS allows you) over the user workspace. CVS client commands are in fact just wrappers above the CVS client/server protocol. If you believe wrappers don't have policy enforcement capabilities, then your attempts to implement this capability in CVS
Re: CVS diff and unknown files.
[ On Saturday, January 29, 2005 at 13:09:59 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. But think about what's really going on. You need to try harder to follow your own advice. If the work will be refused anyway, why would you possibly want to deliberately proceed toward a dead end? If you really, really want to go that route, the add-time test is optional anyway. Sometimes the user does want to add the file to his local workspace even though it would be refused at commit time, or even though it might cause a conflict with some other user's added file at update time. (that's _ALWAYS_ in my own case, actually) What you do privately in your workspace isn't my concern. Exactly, so if I want cvs update to show my locally added files then that's my business -- just as I can make changes to existing files that the commitinfo script might also reject. cvs add and cvs rm are no different than vi -- they make changes in the local workspace and when they are used is NONE OF YOUR CONCERN. If _YOU_ want a cvs add check against repostitory rules in _YOUR_ shop then _YOU_ can add YOUR OWN PRIVATE wrapper script that implements that check for _YOUR_ users and _YOUR_ users _ALONE_. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Triggers (was Re: CVS diff and unknown files.)
[ On Saturday, January 29, 2005 at 15:22:34 (-0800), Paul Sander wrote: ] Subject: Re: Triggers (was Re: CVS diff and unknown files.) But you fail to understand the problem. I understand the problem perfectly. You don't seem to understand the fact that cvs add and cvs rm are supposed to be exactly the same as vi or any other file modification tool (except they operate on the whole file and all its content at once). You don't seem to understand that your insanely powerful drive to have policy controls over everything is quite contrary to the very design goals of CVS overall. CVS is _NOT_ a complete SCM solution and it's not supposed to try to be one either. If you think cvs add (or cvs rm) should invoke addinfo and rminfo scripts on the server then you are using the wrong tool. Wrappers are enablers, not enforcers. By their nature, they cannot be enforcers. Yes, they can be. You need to think a little more outside the box you've built around your ideas. Triggers, on the other hand, are enforcers. Actually that's one thing they cannot be -- at least not at any hard technical controls level. CVS is not a security tool. CVS is not about enforcing policy. CVS is not a complete SCM solution. CVS is a very simple file versioning tool that is designed to keep as much out of the way of the user as is possible and only do exactly what the user wants, and to do it only when the user wants it done, and to only try to do a very select set of operations on a very select set of object types. NOTHING more. If you want more and you think CVS should give you more then you're trying to use the wrong tool for the job. Tell me something. If this were true, why does your commitinfo check for valid RCS ID's? Why don't you periodically run a script to check your sources for them? Because it's easier and infinitely more efficient to have CVS run that script exactly once when it's needed on exactly the files it needs to run it on and never any other time and never on any other files. It's just a reminder though -- it can be foiled, or disabled on purpose for certain files if necessary. Here's another horror story. On another project, we're using a version control system that has a command that does what cvs rm does, but with an instant commit. It also has an option to perform a recursive descent. Why is that a horror story? The whole point of versioning systems is that you can undo your changes. After all you didn't say that the command did what rm -rf /* does when root runs it -- i.e. it didn't make a permanent, irreversible, change that affected everyone. The CM guy for that project was concerned about such capability in the hands of the end users, and raised the issue with management about whether or not to make it an admin function. Than he is, or was at that time, a paranoid idiot who doesn't, or didn't, understand the tools and their utility. It took them a day to restore visibility of all of the files, and a week to redo the legitimate deletions that had accumulated. Clearly that tool wasn't very well designed and implemented to do even the very most basic job of change management. CVS suffers the same vulnerability. Forgive me for thinking your argument is bogus, because experience proves otherwise. vulnerability? Next you'll say that vi suffers the same vulnerabilty too because it's just too easy to delete all the lines in a file with one tiny command. B.S. Many commonly used filesystems suffer the same vulnerabiltiy too -- and quite often CVS repositories live on such filesystems. OOH! The world is such a dangerous and scary place -- we'd better just hide and do nothing! So, what you're recommending is that I rewrite the CVS server to fix my problem. No, just the client. You might want to add other supplementary server-like programs that run on the server to go along with CVS, and they might be invoke by your new client. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Triggers (was Re: CVS diff and unknown files.)
[ On Sunday, January 30, 2005 at 16:45:35 (-0800), Paul Sander wrote: ] Subject: Re: Triggers (was Re: CVS diff and unknown files.) It's not so unusual for people who have done SCM for many years on large and varied projects. Well it depends -- you seem to belong to a (hopefully small and dwindling) group of extremely policy centered, control oriented, SCM managers. Not every large shop (still) does things that way. Lots of very large and diverse projects use CVS quite successfully without any policy enforcement at the CVS repository level. Software development and management doesn't have to be hierarchically and strictly controlled in the way you seem to think it should. The tools don't have to get in the way of the users. Change tracking tools like CVS really should only ever track changes, and the only server-side scripting that's needed to do that is the kind that CVS more or less has already: hooks to make flexible site-specific reporting easier to implement. Your style of SCM would be much better matched to something like Aegis. Why don't you go away from CVS and play with Aegis for a while. You might need a bit of a paradigm shift at the management level to make good use of it, but it really will give you far more control than you could ever get from anything even remotely like CVS. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
[ On , January 31, 2005 at 20:30:21 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. Don't you wish to even try to understand the suggestion? The suggestion is: invoke *the same triggers* both at 'cvs add' and 'cvs commit' time, -- there is no need for separate triggers. No, using the same scripting hook at both add and commit times would be bad, VERY bad. (maybe IFF one had add-time hooks then one might use one script in both the addinfo and commitinfo configurations, which might conceptually be called using the same triggers, but that would of course only be possible if one could/would contact the server at add time and if one did actaully have an addinfo script hook configuration file. ;-) -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Jan 30, 2005, at 6:40 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. A commitinfo trigger can always refuse a file for which cvs add completed successfully. There's nothing new here. If you don't like that, then don't use commitinfo. I propose to use commit-time triggers by cvs add -c time instead of special add-to-repository-time triggers. In my design the triggers are the same, so there is no such problem. Either the file is OK for repository or not, -- simple and clear. The less problems, -- the better. Okay, don't use the add-time triggers in your shop. No one is forcing you to. Don't you wish to even try to understand the suggestion? The suggestion is: invoke *the same triggers* both at 'cvs add' and 'cvs commit' time, -- there is no need for separate triggers. In your design there is OK for addition, but wrong for commit that IMHO is a nonsense. I believe such a design is seriously flawed, sorry. Wait a second. The OK for addition, but wrong for commit is exactly the status quo. Yes, but you propose to improve this using some new thing called add-time triggers, and I try to explain that you will get even better results if you invoke commit-time triggers at add-time. The cvs add command succeeds, cvs commit fails due to commitinfo. What I'm proposing is bad for addition, bad for commit, where cvs add fails on those occasions when we know at that moment that cvs commit will also fail. Why don't just run *the same* script on addition to see if it would actually fail? Why do you need *separate* scripts? That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are clearly not ready to check at add time. Well, if I understand correctly, your intentionally want to have weaker checks at add-time than at commit-time. Instead, you can do it in the commit-time trigger by skipping some of the tests if the file in question is new one. What's new is that we can cause cvs add to fail under certain conditions that we know in advance will cause commitinfo to refuse a file. To make sure that the condition is checked, we do it a second time before commitinfo, because some users insist on defeating it the first time. What functionality is lacking? cvs -n ci allows you to do it. All you require is cvs add to *enforce* the checks. I have two levels of objection here: 1. Enforcement by cvs add of the checks doesn't require introduction of separate add triggers as usual commit triggers could do the job as well. My argument is that it does not in fact do the job as well. I've given a number of reasons why in earlier messages. No, you didn't. Or at least I somehow missed them. The fact that currently CVS doesn't invoke any triggers at add-time has nothing to do with my objection. The question is what is so different about add-time triggers from the point of view of *server* so that it's not enough to just invoke commit-time scripts at the add-time? 2. Enforcement by cvs add of the checks is wrong idea by itself as CVS is not a project management tool and should not be. If your project indeed requires such things, let users execute your wrappers instead of direct CVS commands. Wrappers are not capable of enforcing policy by their nature. Triggers are. I've explained why this is so, also. You've indeed tried to explain, but I don't see anybody but you who agrees with the explanation. One of my argument is that triggers, being run on the server, have no way to impose any policies with respect to working copies, which are under the full control of clients. [...] Can you suggest another way to enforce add-time policy in a way that's centrally controlled by the CVS admin? Sure. Commit
Re: CVS diff and unknown files.
Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Todd Denniston [EMAIL PROTECTED] writes: If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer is through appropriate error message, as usual. Please notice that with separate add-to-working-copy-time triggers the situation at commit time is exactly the same as those triggers must be run at commit time anyway. What's an answer to your question in this case? There is a certain amount beauty in the simplicity in keeping the status quo, which works. :) Unfortunately, it doesn't work, sorry -- that's why I've initiated this thread in the first place. There is also beauty in having the options you want, and none that get in other peoples way. For one of these options much more energy must be expended. :) That's why I've tried to suggest a way to implement things that is rather simple. Still it provides an option to check if a new file will be allowed to go into repository. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote: [...] If you consider my suggestion, there will be no such a beast as add-to-working-copy-time trigger. The commit trigger will notice the file is new and invoke appropriate additional actions (if any). That's all. There is absolutely no need for separate add-to-working-copy-time triggers. Clients still have ability to check if their new files will be accepted by the repository using cvs -n commit. What you suggest is exactly the status quo. The problem is that the status quo fails to meet the needs of part of the CVS community. The reason is because there's an underlying assumption that project policies are voluntary. That assumption is false, and for good reason. It seems that you attempt to turn CVS itself into a project management tool. If that's your actual intention, please say it aloud, and I'll immediately stop all of my previous arguments and replace them with a single one: CVS should not be turned into a project management tool. Meanwhile, everything I write below is written in an assumption that *CVS* still is only *concurrent versions system*, not a project management one. From this point of view the only essential thing for CVS w.r.t. project management is to provide just enough functionality to allow to build project management tools on top of it. Where I work, our projects run for several years and have several teams come in to do different things over its lifetime. (The company maintains its market responsiveness by running multiple similar projects concurrently, which allows several product releases per year. I won't go into why this is the case, but suffice it to say that it goes as fast as it goes and there's no speeding things up.) Over the lifetime of the project, the number of files under source control swells up well into the 6-figure range. To manage the complexity and to assist the human factors of exploration, we live on certain conventions. We have conventions for directory structure, conventions for types of data that sit in what directories, and dozens of naming conventions for files and directories. Our test suites have many optional features, and different sets of these optional features are required to run in different directories. Violations of the conventions can cause the test suites to run incorrectly. Because no errors are reported, there may be significant delays until the problems are detected. At that time, the cost to repair the defects may be huge, in the 6-figure range. And this doesn't consider the humiliation felt by the poor guy who made the typo while creating the file. IMHO in your case you shouldn't teach users to use CVS at all, -- you should teach them to use your project management tool, so they won't be aware about cvs add at all. If CVS lacks some functionality and that prevents you from building your tools on top of it, please provide some evidence this functionality is a must to achieve what you need. Therein lies the justification for add-time policy checking. Yes, commit-time checking will still save many thousands of dollars in repairs, but add-time policy checking saves even more. CVS doesn't prevent you from implementing whatever add-time checks you need on the client side. If you think otherwise, please provide an evidence. And true, the projects I describe don't use CVS. But in the past at another company that produced similar products using similar processes, we did in fact use CVS, and we faced the same problems. Most of the people in this forum don't seem to face these kinds of problems to this extent, but anyone who does cross-platform development faces similar problems. These problems are an issue of a good project management tool, not CVS. If you don't have suitable project management tools, it's not CVS problem. It would be CVS problem if it didn't provide enough functionality to allow you to build a suitable project management tool on top of it. If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer is through appropriate error message, as usual. Please notice that with separate add-to-working-copy-time triggers the situation at commit time is exactly the same as those triggers must be run at commit time anyway. What's an answer to your question in this case? The answer lies not in the if the trigger runs, but when. History has shown that defects are easier, faster, and cheaper to fix when detected early.
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: If cvs add will only warn about the problems, -- that's OK with me as a user. Actually, the way I see the situation is it only prevents the add if you have requested the check with -c, if you have not used -c there is no connection to the server and therefor can be no warning or prevention. Actually, to err on the side of safety (which I define as policy enforcement in this case), I recommend that the trigger be enabled by default. The power users can turn it off in their .cvsrc files. I have two reasons for this: The first is that they're the ones who express an opinion and there are fewer of them than there are ordinary users, and the second is that they're the ones most capable of making the change in their own environments. The fundamental problem with your approach is that policy enforcement at the client side is not CVS business. You still didn't explain what's wrong with writing your own scripts on top of CVS to enforce whatever policies you wish on the client side, or, if there is nothing wrong about it, how CVS prevents you from enforcing whatever policies you need on the client side. This opinion hasn't been clear in all of my posts, but this is how I really think it should work. For me this point has been clear from the very beginning. On this point I seem to be getting overruled because most of the members of this group are power users and don't adequately represent the end user community. It seems you miss the point, at least my point. I in fact don't care much if -c is default or not provided CVS still allows me to add files to the working copy offline. I care about it as a (hopefully rather experienced) programmer that immediately sees fundamental deficiencies in the underlying design. Not being CVS designer I don't in fact care about it that much either, -- just tried to explain an alternative design that I believe is better. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. A commitinfo trigger can always refuse a file for which cvs add completed successfully. There's nothing new here. If you don't like that, then don't use commitinfo. In my design the triggers are the same, so there is no such problem. Either the file is OK for repository or not, -- simple and clear. The less problems, -- the better. In your design there is OK for addition, but wrong for commit that IMHO is a nonsense. I believe such a design is seriously flawed, sorry. What's new is that we can cause cvs add to fail under certain conditions that we know in advance will cause commitinfo to refuse a file. To make sure that the condition is checked, we do it a second time before commitinfo, because some users insist on defeating it the first time. What functionality is lacking? cvs -n ci allows you to do it. All you require is cvs add to *enforce* the checks. I have two levels of objection here: 1. Enforcement by cvs add of the checks doesn't require introduction of separate add triggers as usual commit triggers could do the job as well. 2. Enforcement by cvs add of the checks is wrong idea by itself as CVS is not a project management tool and should not be. If your project indeed requires such things, let users execute your wrappers instead of direct CVS commands. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? What I mean by add-time is the moment in which the user invokes the cvs add command. The canonical example of such a trigger is one that enforces naming conventions, but there are other reasons to control what the user can add. (Some shops don't want users creating directories, for example, and require the CM team to do it for them.) So, provided that cvs add adds the file to the working copy, your definition means add-time to working copy. Requiring server triggers to be run at add-time to working copy seems rather strange design choice in my opinion. Can you suggest another way to enforce add-time policy in a way that's centrally controlled by the CVS admin? Sure. Commit triggers. If cvs add is capable to invoke them, if it invokes them by default, and if trigger failure results in a warning or in error are additional concerns. The primary concern is that separate add-time triggers are not required. BTW, if you believe your project indeed requires it, arrange wrappers that clients will run instead of cvs add. In fact, as you requirements are in the field of project management, your users should never invoke CVS commands directly, -- it's the job of your project management tool to invoke CVS commands when required. When cvs add runs, I don't care whether or not the CVS server modifies the repository. Some people seem to think that running cvs add while
Re: Triggers (was Re: CVS diff and unknown files.)
[...] Sorry, I've skipped all the above. Paul, your vision of the software world, including client/server, wrappers, triggers, scripts, libraries, security, etc. seems to be so unusual that it makes it very difficult to discuss these things with you. It seems you leave in an entirely different world and therefore need entirely different tools. As a suggestion, don't give computers to the users, -- only dumb terminals connected to a server where all the policies are enforced the way you like. I mean it, really, that seems to be the only perfect solution to all of your problems. Better yet, whatever the users do, the result should be exactly the same, otherwise some monkey will find a way to misuse the tools and will waste a few days of his precious time trying to recover. Sorry for the sarcasm above, -- I'm really sorry you need to live in such a world and I really don't see how CVS can help you. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 30, 2005, at 2:18 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Todd Denniston [EMAIL PROTECTED] writes: If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer is through appropriate error message, as usual. Please notice that with separate add-to-working-copy-time triggers the situation at commit time is exactly the same as those triggers must be run at commit time anyway. What's an answer to your question in this case? There is a certain amount beauty in the simplicity in keeping the status quo, which works. :) Unfortunately, it doesn't work, sorry -- that's why I've initiated this thread in the first place. Huh? You know what status quo means, right? It means the way things are. You seem to be arguing both ways. Would you post a message stating your point of view, completely, please? Thanks! There is also beauty in having the options you want, and none that get in other peoples way. For one of these options much more energy must be expended. :) That's why I've tried to suggest a way to implement things that is rather simple. Still it provides an option to check if a new file will be allowed to go into repository. Unfortunately, if checking for compliance is an option, it will never (or at least very rarely) be taken for one of the following reasons: - They think they are already in compliance and don't need to check. - They think they have legitimate cause to break policy. - They're unaware of the policy. - They forget to check. It's possible to have a third party check periodically, as Greg suggests. But that method isn't as effective as automatic enforcement at the moment the violation occurs. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 30, 2005, at 3:28 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote: [...] If you consider my suggestion, there will be no such a beast as add-to-working-copy-time trigger. The commit trigger will notice the file is new and invoke appropriate additional actions (if any). That's all. There is absolutely no need for separate add-to-working-copy-time triggers. Clients still have ability to check if their new files will be accepted by the repository using cvs -n commit. What you suggest is exactly the status quo. The problem is that the status quo fails to meet the needs of part of the CVS community. The reason is because there's an underlying assumption that project policies are voluntary. That assumption is false, and for good reason. It seems that you attempt to turn CVS itself into a project management tool. If that's your actual intention, please say it aloud, and I'll immediately stop all of my previous arguments and replace them with a single one: CVS should not be turned into a project management tool. Project management is not something that can be implemented in a single tool. It encompasses a lot of things ranging from identifying a market all the way to end-of-life support. Accomplishing it well involves a great many things, including planning and scheduling (the part that project management tools do), methodology (including policies, toolsets, and disciplines), and many other things, all of which must integrate and interoperate with each each other successfully. I'm not asking for CVS to be a project management tool in any sense. What I'm asking for is a hook on which to hang other parts of project management. The commitinfo hook already exists, and it's effective at what it does. All I'm asking for is another hook, to be used as the project sees fit. Where I work, our projects run for several years and have several teams come in to do different things over its lifetime. (The company maintains its market responsiveness by running multiple similar projects concurrently, which allows several product releases per year. I won't go into why this is the case, but suffice it to say that it goes as fast as it goes and there's no speeding things up.) Over the lifetime of the project, the number of files under source control swells up well into the 6-figure range. To manage the complexity and to assist the human factors of exploration, we live on certain conventions. We have conventions for directory structure, conventions for types of data that sit in what directories, and dozens of naming conventions for files and directories. Our test suites have many optional features, and different sets of these optional features are required to run in different directories. Violations of the conventions can cause the test suites to run incorrectly. Because no errors are reported, there may be significant delays until the problems are detected. At that time, the cost to repair the defects may be huge, in the 6-figure range. And this doesn't consider the humiliation felt by the poor guy who made the typo while creating the file. IMHO in your case you shouldn't teach users to use CVS at all, -- you should teach them to use your project management tool, so they won't be aware about cvs add at all. If CVS lacks some functionality and that prevents you from building your tools on top of it, please provide some evidence this functionality is a must to achieve what you need. Okay, CVS lacks an ability for cvs add to invoke a script, in the same manner that cvs commit invokes scripts via the commitinfo file, to validate the addition. Therein lies the justification for add-time policy checking. Yes, commit-time checking will still save many thousands of dollars in repairs, but add-time policy checking saves even more. CVS doesn't prevent you from implementing whatever add-time checks you need on the client side. If you think otherwise, please provide an evidence. See above. And true, the projects I describe don't use CVS. But in the past at another company that produced similar products using similar processes, we did in fact use CVS, and we faced the same problems. Most of the people in this forum don't seem to face these kinds of problems to this extent, but anyone who does cross-platform development faces similar problems. These problems are an issue of a good project management tool, not CVS. If you don't have suitable project management tools, it's not CVS problem. It would be CVS problem if it didn't provide enough functionality to allow you to build a suitable project management tool on top of it. It doesn't see above. If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal
Re: CVS diff and unknown files.
On Jan 30, 2005, at 3:42 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: If cvs add will only warn about the problems, -- that's OK with me as a user. Actually, the way I see the situation is it only prevents the add if you have requested the check with -c, if you have not used -c there is no connection to the server and therefor can be no warning or prevention. Actually, to err on the side of safety (which I define as policy enforcement in this case), I recommend that the trigger be enabled by default. The power users can turn it off in their .cvsrc files. I have two reasons for this: The first is that they're the ones who express an opinion and there are fewer of them than there are ordinary users, and the second is that they're the ones most capable of making the change in their own environments. The fundamental problem with your approach is that policy enforcement at the client side is not CVS business. You still didn't explain what's wrong with writing your own scripts on top of CVS to enforce whatever policies you wish on the client side, or, if there is nothing wrong about it, how CVS prevents you from enforcing whatever policies you need on the client side. I agree that there's a limit beyond which CVS should not interfere with the user. The user should, for example, be able to use whatever tools in his workspace as he deems necessary, provided it interoperates with rest of the methodology. Creating and deleting files in the workspace is clearly within the user's purview. However, as soon as the user declares an intent to store a file in the repository, he begins to subject himself to the policies of the project. Sooner or later, before he commits his work, he must comply. Granted the time between cvs add and cvs commit is kind of a grey area, and the scope of add-time policy enforcement is pretty limited. (Access control and naming conventions are pretty much all you can do at that point. Arguing that it's reasonable to check the content of a file (for example) at that point is bogus, in my opinion.) But for those things that are reasonable to check, adding to CVS the ability to check them is totally reasonable. On this point I seem to be getting overruled because most of the members of this group are power users and don't adequately represent the end user community. It seems you miss the point, at least my point. I in fact don't care much if -c is default or not provided CVS still allows me to add files to the working copy offline. I care about it as a (hopefully rather experienced) programmer that immediately sees fundamental deficiencies in the underlying design. Not being CVS designer I don't in fact care about it that much either, -- just tried to explain an alternative design that I believe is better. The add-time trigger proposal accommodates your requirement to have cvs add complete successfully when working offline. In your case, detection violations of add-time policy would be deferred until commit time, and you might be forced into some significant rework. You're clearly willing to take that risk and pay the cost, and that's your prerogative. In my opinion, having the user run cvs -n commit right after cvs add is not at all a better solution to this particular problem. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 30, 2005, at 6:40 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. A commitinfo trigger can always refuse a file for which cvs add completed successfully. There's nothing new here. If you don't like that, then don't use commitinfo. In my design the triggers are the same, so there is no such problem. Either the file is OK for repository or not, -- simple and clear. The less problems, -- the better. Okay, don't use the add-time triggers in your shop. No one is forcing you to. In your design there is OK for addition, but wrong for commit that IMHO is a nonsense. I believe such a design is seriously flawed, sorry. Wait a second. The OK for addition, but wrong for commit is exactly the status quo. The cvs add command succeeds, cvs commit fails due to commitinfo. What I'm proposing is bad for addition, bad for commit, where cvs add fails on those occasions when we know at that moment that cvs commit will also fail. That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are clearly not ready to check at add time. What's new is that we can cause cvs add to fail under certain conditions that we know in advance will cause commitinfo to refuse a file. To make sure that the condition is checked, we do it a second time before commitinfo, because some users insist on defeating it the first time. What functionality is lacking? cvs -n ci allows you to do it. All you require is cvs add to *enforce* the checks. I have two levels of objection here: 1. Enforcement by cvs add of the checks doesn't require introduction of separate add triggers as usual commit triggers could do the job as well. My argument is that it does not in fact do the job as well. I've given a number of reasons why in earlier messages. 2. Enforcement by cvs add of the checks is wrong idea by itself as CVS is not a project management tool and should not be. If your project indeed requires such things, let users execute your wrappers instead of direct CVS commands. Wrappers are not capable of enforcing policy by their nature. Triggers are. I've explained why this is so, also. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? What I mean by add-time is the moment in which the user invokes the cvs add command. The canonical example of such a trigger is one that enforces naming conventions, but there are other reasons to control what the user can add. (Some shops don't want users creating directories, for example, and require the CM team to do it for them.) So, provided that cvs add adds the file to the working copy, your definition means add-time to working copy. Requiring server triggers to be run at add-time to working copy seems rather strange design choice in my opinion. Can you suggest another way to enforce add-time policy in a way
Re: Triggers (was Re: CVS diff and unknown files.)
On Jan 30, 2005, at 7:09 AM, [EMAIL PROTECTED] wrote: Paul, your vision of the software world, including client/server, wrappers, triggers, scripts, libraries, security, etc. seems to be so unusual that it makes it very difficult to discuss these things with you. It seems you leave in an entirely different world and therefore need entirely different tools. It's not so unusual for people who have done SCM for many years on large and varied projects. As a suggestion, don't give computers to the users, -- only dumb terminals connected to a server where all the policies are enforced the way you like. I mean it, really, that seems to be the only perfect solution to all of your problems. Better yet, whatever the users do, the result should be exactly the same, otherwise some monkey will find a way to misuse the tools and will waste a few days of his precious time trying to recover. There are technical solutions to most of the problems I've encountered so far, certainly all of the ones I've ever brought up in this forum. Hobbling the users for my benefit isn't the answer in the long term. Sorry for the sarcasm above, -- I'm really sorry you need to live in such a world and I really don't see how CVS can help you. As critical as I am about CVS, I really have only 3 or 4 really hot buttons about it. Triggers happen to be one of them. :-) -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. A commitinfo trigger can always refuse a file for which cvs add completed successfully. There's nothing new here. If you don't like that, then don't use commitinfo. What's new is that we can cause cvs add to fail under certain conditions that we know in advance will cause commitinfo to refuse a file. To make sure that the condition is checked, we do it a second time before commitinfo, because some users insist on defeating it the first time. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? What I mean by add-time is the moment in which the user invokes the cvs add command. The canonical example of such a trigger is one that enforces naming conventions, but there are other reasons to control what the user can add. (Some shops don't want users creating directories, for example, and require the CM team to do it for them.) So, provided that cvs add adds the file to the working copy, your definition means add-time to working copy. Requiring server triggers to be run at add-time to working copy seems rather strange design choice in my opinion. Can you suggest another way to enforce add-time policy in a way that's centrally controlled by the CVS admin? When cvs add runs, I don't care whether or not the CVS server modifies the repository. Some people seem to think that running cvs add while disconnected is a useful thing to do. (I take the attitude that client/server applications shouldn't be expected to run without a working network, so I'd never run any CVS command when I was unable to connect to the server.) Very strange attitude. And a very unusual definition of expectations associated with client/server applications. Having this definition, mail client isn't supposed to let you do anything with the mail on your computer without a working network?! I rely heavily on IMAP and SMTP for mail transport. At work, my mail client lives on an NFS server. So no, I don't expect mail to work when the network is down. BTW, the definition of client/server implies the presence of a network for communication between the two parts, without which the application fails. The other method is usually called monolithic, in which the application is self-contained. CVS works both ways, but most of us prefer a remote repository, hence the client/server implementation. However, since triggers enforce policy and must not be defeatable, e.g. by changing one's path or bypassing a wrapper or hacking the client machine, they're best implemented as a server feature. It's for that reason, assuming add-time triggers are implemented, they require a connection to the server. The add-time triggers you are advocating would then create an unfortunate precedent of preventing user from modifying his working copy at a will of CVS repository administrator! PLEASE, DON'T DO IT TO CVS! Sorry for shouting. Fortunately, as triggers are run on the server,
Re: CVS diff and unknown files.
On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: If cvs add will only warn about the problems, -- that's OK with me as a user. Actually, the way I see the situation is it only prevents the add if you have requested the check with -c, if you have not used -c there is no connection to the server and therefor can be no warning or prevention. Actually, to err on the side of safety (which I define as policy enforcement in this case), I recommend that the trigger be enabled by default. The power users can turn it off in their .cvsrc files. I have two reasons for this: The first is that they're the ones who express an opinion and there are fewer of them than there are ordinary users, and the second is that they're the ones most capable of making the change in their own environments. This opinion hasn't been clear in all of my posts, but this is how I really think it should work. On this point I seem to be getting overruled because most of the members of this group are power users and don't adequately represent the end user community. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 28, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. Careful, Last discussion time it was indicated that if add triggers were to be added, then for them to be useful they would have to run at add time (when the flag requesting them was passed) AND more importantly at commit time, so commit on the server would if it had never seen the file before run the add trigger and then the normal commit trigger. So as long as the add trigger (script) had not changed between 'cvs add -c' (IIRC that was the flag) and commit time and the trigger allowed the add, then the server would at commit time run the add trigger, get a pass run any commit triggers, get a pass if appropriate. So in adding the add trigger functionality, the person patching CVS would have to recognize the signals in the code indicating new file/directory at commit, and connect the hook there too. If you consider my suggestion, there will be no such a beast as add-to-working-copy-time trigger. The commit trigger will notice the file is new and invoke appropriate additional actions (if any). That's all. There is absolutely no need for separate add-to-working-copy-time triggers. Clients still have ability to check if their new files will be accepted by the repository using cvs -n commit. What you suggest is exactly the status quo. The problem is that the status quo fails to meet the needs of part of the CVS community. The reason is because there's an underlying assumption that project policies are voluntary. That assumption is false, and for good reason. Where I work, our projects run for several years and have several teams come in to do different things over its lifetime. (The company maintains its market responsiveness by running multiple similar projects concurrently, which allows several product releases per year. I won't go into why this is the case, but suffice it to say that it goes as fast as it goes and there's no speeding things up.) Over the lifetime of the project, the number of files under source control swells up well into the 6-figure range. To manage the complexity and to assist the human factors of exploration, we live on certain conventions. We have conventions for directory structure, conventions for types of data that sit in what directories, and dozens of naming conventions for files and directories. Our test suites have many optional features, and different sets of these optional features are required to run in different directories. Violations of the conventions can cause the test suites to run incorrectly. Because no errors are reported, there may be significant delays until the problems are detected. At that time, the cost to repair the defects may be huge, in the 6-figure range. And this doesn't consider the humiliation felt by the poor guy who made the typo while creating the file. Therein lies the justification for add-time policy checking. Yes, commit-time checking will still save many thousands of dollars in repairs, but add-time policy checking saves even more. And true, the projects I describe don't use CVS. But in the past at another company that produced similar products using similar processes, we did in fact use CVS, and we faced the same problems. Most of the people in this forum don't seem to face these kinds of problems to this extent, but anyone who does cross-platform development faces similar problems. If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer is
Re: Triggers (was Re: CVS diff and unknown files.)
On Jan 28, 2005, at 3:55 PM, [EMAIL PROTECTED] wrote: [ On Friday, January 28, 2005 at 03:26:05 (-0800), Paul Sander wrote: ] Subject: Triggers (was Re: CVS diff and unknown files.) Sigh. Just because you haven't found a use for add-time triggers within the scope of your blinders, doesn't mean that no one has. You don't seem to understand. A new file, from the repository's point of view, thus from any repository policy point of view, does not exist until commit time. The existing commitinfo hooks are more than adequate enough to enforce any repository policy on the new file, be it by name, or by content. (my own commitinfo scripts check that the new file has a proper RCS Id, for example) I understand perfectly what you're saying and why. But you fail to understand the problem. I'm not talking about anything from the repository point of view; my arguments are from the user's and project manager's point of view. Using naming conventions as an example, it's true that at the point the project ships, it doesn't matter from a quality for feature perspective when a defect was found and fixed, as long as the policy is checked sometime before the release. What I'm talking about is something else: The cost to fix defects. Once again, history has shown that defects found early are easier, faster, and cheaper to fix than defects that are found late. If someone creates a new file and spends a day integrating it into the project only to have it rejected by a commit due to a naming policy violation, then he gets to spend another day fixing the mistake. This is an unnecessary effort if only the developer had found out in the morning that the name of his file was bad rather than in the evening. Also, wrappers are not always the answer. Wrappers are always the answer when you want to do something policy related in the working directory. THEY MUST BE. The core CVS program, by design, does not involve itself in policy matters affecting the working directories. The core CVS program is not a complete SCM platform. Wrappers are enablers, not enforcers. By their nature, they cannot be enforcers. You can automate some process using some script, and you can even mandate its use. But you can't enforce its use because as long as there's something more primitive available the user can drop down and use that instead. Triggers, on the other hand, are enforcers. They block higher-level functions when their programmed preconditions aren't met, and they force actions when their programmed preconditions are met. Wrappers are simply incapable of this. - Wrappers can be subverted by the users, sometimes accidentally, sometimes deliberately. If your users are so lazy, ill informed, or antagonistic of their fellow workers, that your shop worries about users subverting wrapper programs, even accidentally, then CVS is _NOT_ the right tool for your shop. Tell me something. If this were true, why does your commitinfo check for valid RCS ID's? Why don't you periodically run a script to check your sources for them? - Some users must be kept away from certain features. If your users are so lazy, ill informed, or antagonistic of their fellow workers, that your shop worries about users accessing certain features, even accidentally, then CVS is _NOT_ the right tool for your shop. Here's another horror story. On another project, we're using a version control system that has a command that does what cvs rm does, but with an instant commit. It also has an option to perform a recursive descent. (Those who believe that remove/add of entire directory structures is a reasonable implementation of the ability to rename a directory can understand the need for this.) The CM guy for that project was concerned about such capability in the hands of the end users, and raised the issue with management about whether or not to make it an admin function. Every end user of that tool undergoes 2-3 hours of training and is given documentation. They also undergo another 1-2 hours to learn how the tool is tightly integrated with one of our mission critical tools. There are also on-site mentors and online support for the tool. It was on this basis that senior team leads and management crushed the CM guy mercilessly, claiming that no one would possibly be so irresponsible as to use that command in a damaging way. Within two weeks of that argument, someone used that command at the very top of their source tree. (This person reported directly to the guy who made the responsibility argument.) It took them a day to restore visibility of all of the files, and a week to redo the legitimate deletions that had accumulated. Within a week after completing the recovery, someone else used that command again, at the very top of their source tree. CVS suffers the same vulnerability. Forgive me for thinking your argument is bogus, because experience proves otherwise. - Access to certain features must
Re: CVS diff and unknown files.
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: [...] What register adds in the repo nonsense are you talking about? The proposal I made simply requires a contact with the server to run the add-time triggers; it does NOT require add-time modifications of the repository by the CVS server itself. If the triggers drop turds in the repository, then that's a different matter. Also remember that my proposal includes a way to shut off the add-time triggers as a client configuration, deferring them to commit time to accommodate users like you. Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? What I mean by add-time is the moment in which the user invokes the cvs add command. The canonical example of such a trigger is one that enforces naming conventions, but there are other reasons to control what the user can add. (Some shops don't want users creating directories, for example, and require the CM team to do it for them.) When cvs add runs, I don't care whether or not the CVS server modifies the repository. Some people seem to think that running cvs add while disconnected is a useful thing to do. (I take the attitude that client/server applications shouldn't be expected to run without a working network, so I'd never run any CVS command when I was unable to connect to the server.) However, since triggers enforce policy and must not be defeatable, e.g. by changing one's path or bypassing a wrapper or hacking the client machine, they're best implemented as a server feature. It's for that reason, assuming add-time triggers are implemented, they require a connection to the server. In fact the semantics of proposed 'cvs add -c' is: add this file to the working copy and check if the repository will allow me to commit this new file if I decide to. In this semantic only the latter part has anything to do with the repository, and it is commit, not add, that's why I suggested 'cvs commit' would be more logical place to check for such things. Certain conditions that will allow me to commit this new file if I decide to can be checked at the time the user invokes the cvs add command. The rationale is that if a failure condition can be detected at add-time then any conditions deriving from those creating the failure condition can be halted, thus avoiding costly recovery action at the time when the first commit actually fails. For example, suppose a mixed Windows/Unix shop requires all files to have upper-case 8.3 file names. A new programmer splits a header file and creates a new foo.h. He adds the file, then proceeds to modify all of the source files to include the new foo.h. Then he updates all of the dependencies in his makefiles. He builds and tests on Unix. He types cvs commit, types a very detailed log of his actions, and finally punches the screen. This person might have saved a day's work, his equipment, and his knuckles if only cvs add had said Sorry, this new file violates our naming policy, try renaming it to FOO.H instead. To get your semantics, it seems you need a new operation with the semantics add the file to the working copy and to the repository, but don't give it to anybody on 'cvs update' yet, until I latter commit the addition. Do you propose exactly this? How could it be done without write access to the repository? The semantics I want are to
Triggers (was Re: CVS diff and unknown files.)
On Jan 27, 2005, at 12:36 PM, [EMAIL PROTECTED] wrote: [ On Wednesday, January 26, 2005 at 21:05:46 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. I had hoped that this was clear in the last go-round, but apparently not. Developers who think they require add-time triggers need their heads examined, but if they really think they want to implement them then they have all the power of any programming language they desire to do so in a pogram that they build over and above and outside the core CVS program. Sigh. Just because you haven't found a use for add-time triggers within the scope of your blinders, doesn't mean that no one has. Also, wrappers are not always the answer. Sure, it's possible to duplicate the CVS command line and invokes whatever tools enforce policy for the given shop. The thing is, it's a huge duplication of effort when many shops do it, plus the wrappers must contact the server to insure uniform enforcement. We already have code that does that, and it's called cvs. It's faster, cheaper, easier, and more robust to add it to CVS. Agreed. But the tool must be sufficiently flexible to allow robust implementations of policies. Sometimes triggers are the right way (and wrapper scripts are not), and we've identified one area here where CVS is not sufficiently flexible. That's pure and utter bullshit. These so poortly named triggers in CVS now were a poor idea from the start which have been misperceived by folks such as yourself (and no doubt your blathering on about your misperceptions has only spread the problem further) and they've been rather poorly implemented to boot. I agree that triggers as implemented by CVS are poor. They're better than they once were, but they're still poor. That doesn't mean they're not needed or shouldn't be used (or fixed). If you think you want policy control over working directories then either you're using the wrong tool for the job, or you need to think more like a true toolsmith and build your policy enforcement tools over and above and outside the core CVS program where they belong. Are you arguing here that I should not be using triggers, or that I should not be using CVS? If the former, then Greg, the ignorance shown by that statement utterly astonishes. My current employment has me implementing process automation and policy enforcement every day. One of my current projects is to design an engineering change order (ECO) process and the necessary tools to implement it. This is the third such process that I have done (for different projects) in the past two years. We don't use CVS for these projects, but rather a home-grown system. Until recently it had no triggers, and even now their implementation is incomplete. In other words, we face the same limitations with this system as we would have with CVS. People (other than myself, working on other projects) demanded that triggers be added to this version control system for the following reasons, which are valid: - The command given by the user doesn't always have enough information for a wrapper to determine all of the artifacts affected by the trigger. Some processing by the version control system is required before refinements take over. - Wrappers can be subverted by the users, sometimes accidentally, sometimes deliberately. - Some users must be kept away from certain features. - Access to certain features must be restricted conditionally upon the user's specific task. - The runtime cost of certain actions is much cheaper when invoked at a level below the command line. - In client/server environments, certain actions must be performed in the context of the server, not in the context of the user. The security model is such that access to the server is given only to certain trusted applications. - Wrappers can only add functionality. They cannot remove or limit existing functionality. - The actions of wrappers cannot be incorporated into the back-end transactions implemented by the version control primitives. - Wrappers cannot utilize or control primitive operations at a lower level than the command line. Now I will give an example that will absolutely horrify you: We have actually identified cases where our counterparts of cvs checkout and cvs update must be restricted in ways that don't involve classical access control. This directly counters your assertion that policies don't reign over individuals' workspaces. The requirements are: - There is a notion of development phase and frozen phase. - Different branches of the project can be in different phases. - During the development phase, all users have access to all versions of all files. - During the frozen phase: - Users who work
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? What I mean by add-time is the moment in which the user invokes the cvs add command. The canonical example of such a trigger is one that enforces naming conventions, but there are other reasons to control what the user can add. (Some shops don't want users creating directories, for example, and require the CM team to do it for them.) So, provided that cvs add adds the file to the working copy, your definition means add-time to working copy. Requiring server triggers to be run at add-time to working copy seems rather strange design choice in my opinion. When cvs add runs, I don't care whether or not the CVS server modifies the repository. Some people seem to think that running cvs add while disconnected is a useful thing to do. (I take the attitude that client/server applications shouldn't be expected to run without a working network, so I'd never run any CVS command when I was unable to connect to the server.) Very strange attitude. And a very unusual definition of expectations associated with client/server applications. Having this definition, mail client isn't supposed to let you do anything with the mail on your computer without a working network?! However, since triggers enforce policy and must not be defeatable, e.g. by changing one's path or bypassing a wrapper or hacking the client machine, they're best implemented as a server feature. It's for that reason, assuming add-time triggers are implemented, they require a connection to the server. The add-time triggers you are advocating would then create an unfortunate precedent of preventing user from modifying his working copy at a will of CVS repository administrator! PLEASE, DON'T DO IT TO CVS! Sorry for shouting. Fortunately, as triggers are run on the server, there is in fact no way to actually impose any policy on the client side. In fact the semantics of proposed 'cvs add -c' is: add this file to the working copy and check if the repository will allow me to commit this new file if I decide to. In this semantic only the latter part has anything to do with the repository, and it is commit, not add, that's why I suggested 'cvs commit' would be more logical place to check for such things. Certain conditions that will allow me to commit this new file if I decide to can be checked at the time the user invokes the cvs add command. The rationale is that if a failure condition can be detected at add-time then any conditions deriving from those creating the failure condition can be halted, thus avoiding costly recovery action at the time when the first commit actually fails. The problem is that you still try at add-to-the-working-copy time to impose policies that in fact make sense at the add-to-repository time. For example, suppose a mixed Windows/Unix shop requires all files to have upper-case
Re: CVS diff and unknown files.
Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. Careful, Last discussion time it was indicated that if add triggers were to be added, then for them to be useful they would have to run at add time (when the flag requesting them was passed) AND more importantly at commit time, so commit on the server would if it had never seen the file before run the add trigger and then the normal commit trigger. So as long as the add trigger (script) had not changed between 'cvs add -c' (IIRC that was the flag) and commit time and the trigger allowed the add, then the server would at commit time run the add trigger, get a pass run any commit triggers, get a pass if appropriate. So in adding the add trigger functionality, the person patching CVS would have to recognize the signals in the code indicating new file/directory at commit, and connect the hook there too. SNIP When cvs add runs, I don't care whether or not the CVS server modifies the repository. Some people seem to think that running cvs add while disconnected is a useful thing to do. (I take the attitude that client/server applications shouldn't be expected to run without a working network, so I'd never run any CVS command when I was unable to connect to the server.) Very strange attitude. And a very unusual definition of expectations associated with client/server applications. Having this definition, mail client isn't supposed to let you do anything with the mail on your computer without a working network?! If you are using IMAP, that is a true statement, for all mail boxes ON the server. If you have downloaded the mail to your local disks you can work with it there off-line (I have this kind of setup). As has been mentioned, the contact to the server for add should require a flag being set (for Paul's group they would put the flag in each of their .cvsrc files). So it does require a working connection, but only if you, like Paul, require add time trigger checking. SNIP For example, suppose a mixed Windows/Unix shop requires all files to have upper-case 8.3 file names. A new programmer splits a header file and creates a new foo.h. He adds the file, then proceeds to modify all of the source files to include the new foo.h. Then he updates all of the dependencies in his makefiles. He builds and tests on Unix. He types cvs commit, types a very detailed log of his actions, and finally punches the screen. This person might have saved a day's work, his equipment, and his knuckles if only cvs add had said Sorry, this new file violates our naming policy, try renaming it to FOO.H instead. ... and what? Is the file added to the working copy or not? If not, then if I've specified a few files, are they all not added, or only those that didn't pass the test? Still I'm opposed to the idea that cvs add would refrain from adding files to the working copy. It's not repository administrator business to decide what I can and what I can't do to my working copy. It could be if it is company policy. Remember those silly things many of us just sign to get hired? (yes bad practice I know) If cvs add will only warn about the problems, -- that's OK with me as a user. Actually, the way I see the situation is it only prevents the add if you have requested the check with -c, if you have not used -c there is no connection to the server and therefor can be no warning or prevention. SNIP It would run the add-time triggers (for the first commit) and then the commit-time triggers. Will cvs -n ci new_file run the triggers in the design you have in mind? Does cvs -n ci file run the commit trigger now (cvs-1.11/1.12)? if yes then the modified version should run the add, if no, then no. SNIP Whatever the reasons for duplication are, the fact is that the server must run add-time triggers when new file is being added to the repository. Adding files to repository is what cvs commit does. Then it's logical for cvs -n commit to run the
Re: CVS diff and unknown files.
Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. Careful, Last discussion time it was indicated that if add triggers were to be added, then for them to be useful they would have to run at add time (when the flag requesting them was passed) AND more importantly at commit time, so commit on the server would if it had never seen the file before run the add trigger and then the normal commit trigger. So as long as the add trigger (script) had not changed between 'cvs add -c' (IIRC that was the flag) and commit time and the trigger allowed the add, then the server would at commit time run the add trigger, get a pass run any commit triggers, get a pass if appropriate. So in adding the add trigger functionality, the person patching CVS would have to recognize the signals in the code indicating new file/directory at commit, and connect the hook there too. If you consider my suggestion, there will be no such a beast as add-to-working-copy-time trigger. The commit trigger will notice the file is new and invoke appropriate additional actions (if any). That's all. There is absolutely no need for separate add-to-working-copy-time triggers. Clients still have ability to check if their new files will be accepted by the repository using cvs -n commit. [...] As has been mentioned, the contact to the server for add should require a flag being set (for Paul's group they would put the flag in each of their .cvsrc files). So it does require a working connection, but only if you, like Paul, require add time trigger checking. With my design you don't have ugly add-to-working-copy-time triggers and still have the functionality of checking if new files are OK from the point of view of repository policies. Usual commit time trigger can do the job. [...] If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer is through appropriate error message, as usual. Please notice that with separate add-to-working-copy-time triggers the situation at commit time is exactly the same as those triggers must be run at commit time anyway. What's an answer to your question in this case? -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Sergei Organov wrote: Todd Denniston [EMAIL PROTECTED] writes: If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer is through appropriate error message, as usual. Please notice that with separate add-to-working-copy-time triggers the situation at commit time is exactly the same as those triggers must be run at commit time anyway. What's an answer to your question in this case? There is a certain amount beauty in the simplicity in keeping the status quo, which works. :) There is also beauty in having the options you want, and none that get in other peoples way. For one of these options much more energy must be expended. :) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Triggers (was Re: CVS diff and unknown files.)
[ On Friday, January 28, 2005 at 03:26:05 (-0800), Paul Sander wrote: ] Subject: Triggers (was Re: CVS diff and unknown files.) Sigh. Just because you haven't found a use for add-time triggers within the scope of your blinders, doesn't mean that no one has. You don't seem to understand. A new file, from the repository's point of view, thus from any repository policy point of view, does not exist until commit time. The existing commitinfo hooks are more than adequate enough to enforce any repository policy on the new file, be it by name, or by content. (my own commitinfo scripts check that the new file has a proper RCS Id, for example) Also, wrappers are not always the answer. Wrappers are always the answer when you want to do something policy related in the working directory. THEY MUST BE. The core CVS program, by design, does not involve itself in policy matters affecting the working directories. The core CVS program is not a complete SCM platform. Are you arguing here that I should not be using triggers, or that I should not be using CVS? If your developers are so lazy, ill informed, or antagonistic of their fellow workers, that your shop needs every little move they make, even in their working directories, mediated by some policy-enforcing big-brother overseerer, then CVS is _NOT_ the right tool for your shop. - Wrappers can be subverted by the users, sometimes accidentally, sometimes deliberately. If your users are so lazy, ill informed, or antagonistic of their fellow workers, that your shop worries about users subverting wrapper programs, even accidentally, then CVS is _NOT_ the right tool for your shop. - Some users must be kept away from certain features. If your users are so lazy, ill informed, or antagonistic of their fellow workers, that your shop worries about users accessing certain features, even accidentally, then CVS is _NOT_ the right tool for your shop. - Access to certain features must be restricted conditionally upon the user's specific task. If your users are so lazy, ill informed, or antagonistic of their fellow workers, that your shop worries about users accessing certain features, even accidentally, then CVS is _NOT_ the right tool for your shop. - In client/server environments, certain actions must be performed in the context of the server, not in the context of the user. Any wrapper script can also contact the server. Write a client/server wrapper scripting environment -- it's trivial to do. The security model is such that access to the server is given only to certain trusted applications. Either make the wrapper a trusted application, or brainwipe your security officer and go find one who actually knows a thing or two about computer security, instead of one who simply reads the Idiots books. - Wrappers can only add functionality. They cannot remove or limit existing functionality. WRONG. Wrapper programs can trivially prevent or mediate all functionality. - Wrappers cannot utilize or control primitive operations at a lower level than the command line. Not my problem! ;-) But, yes, they can -- you have the source. Your wrapper could very easily be any new client front-end that talks to the server, perhaps over multiple channels even. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: [...] What register adds in the repo nonsense are you talking about? The proposal I made simply requires a contact with the server to run the add-time triggers; it does NOT require add-time modifications of the repository by the CVS server itself. If the triggers drop turds in the repository, then that's a different matter. Also remember that my proposal includes a way to shut off the add-time triggers as a client configuration, deferring them to commit time to accommodate users like you. Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? In fact the semantics of proposed 'cvs add -c' is: add this file to the working copy and check if the repository will allow me to commit this new file if I decide to. In this semantic only the latter part has anything to do with the repository, and it is commit, not add, that's why I suggested 'cvs commit' would be more logical place to check for such things. To get your semantics, it seems you need a new operation with the semantics add the file to the working copy and to the repository, but don't give it to anybody on 'cvs update' yet, until I latter commit the addition. Do you propose exactly this? How could it be done without write access to the repository? I had hoped that this was clear in the last go-round, but apparently not. For me it is not, sorry. Let me give yet another example. Suppose I've created a new_file today and have checked it's ok using proposed 'cvs add -c new_file' command. Two days later what I've checked could already be wrong (policy change, another user added the same file, etc.). So there are two questions: 1. How do I repeat my check later? By just repeating 'cvs add -c new_file'? This would produce warnings new_file has already been added that is not a good thing for an operation intended to make checks, I'm afraid. 2. Should 'cvs -n ci new_file' run the same triggers 'cvs add -c new_file' runs? If exactly the same, then why the duplication? Policy goes above -- it is not hard-coded in the core functionality. Agreed. But the tool must be sufficiently flexible to allow robust implementations of policies. Sometimes triggers are the right way (and wrapper scripts are not), and we've identified one area here where CVS is not sufficiently flexible. That's why I insist CVS should have sane set of elementary operations that could be then combined in different ways. I have no objection against compound CVS commands that do multiple things (preferably making them atomic), but existing of corresponding elementary commands is a must, I believe. Designing tools in a different manner results in a lack of flexibility, or at least my experience suggests it does. On Jan 25, 2005, at 9:29 AM, [EMAIL PROTECTED] wrote: Besides, concerning informing the user about problems ASAP, I find myself using 'cvs add' and 'cvs remove' as *late* as possible (as close to the commit as possible) due to the oddities in CVS behavior described below. Consider the following use-case where the intent of tagging is to mark the repository state just before committing of a set of changes that includes adding and/or removing of some files: $ cd working_copy $ echo a a $ cvs add a cvs server: scheduling file `a' for addition cvs server: use 'cvs commit' to add this file permanently [... time passes ... and now I'm ready to commit...] $ cvs update ... $ cvs tag -F before-my-changes cvs server: nothing known about a cvs [server aborted]: correct the above errors first! Oops! Need to remove file back to be able to tag the repository! Doesn't error nothing known about a look funny by the way? Shouldn't 'cvs update' show N meaning nothing known instead of A as the
Re: CVS diff and unknown files.
[ On Wednesday, January 26, 2005 at 21:05:46 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. I had hoped that this was clear in the last go-round, but apparently not. Developers who think they require add-time triggers need their heads examined, but if they really think they want to implement them then they have all the power of any programming language they desire to do so in a pogram that they build over and above and outside the core CVS program. Agreed. But the tool must be sufficiently flexible to allow robust implementations of policies. Sometimes triggers are the right way (and wrapper scripts are not), and we've identified one area here where CVS is not sufficiently flexible. That's pure and utter bullshit. These so poortly named triggers in CVS now were a poor idea from the start which have been misperceived by folks such as yourself (and no doubt your blathering on about your misperceptions has only spread the problem further) and they've been rather poorly implemented to boot. If you think you want policy control over working directories then either you're using the wrong tool for the job, or you need to think more like a true toolsmith and build your policy enforcement tools over and above and outside the core CVS program where they belong. It's frequently said to users that tags apply to the versions in your workspace when cvs tag is used. If that's the way it is being said then that is misleading. Tags applied by the cvs tag command go, by default, against the BASE REVISIONS of the files in the workspace. (and besides, files in the working directories don't really have revisions -- they were derived from their base revision and they may, or may not, have local changes) But on the other hand, having an atomic commit/tag operation would be useful if it existed... once again you're trying to use, or thinking of using, the wrong tool for the job. CVS does not, should not, and need not, try to guarantee atomicity for higher-level SCM abstractions. The problem was that cvs tag was complaining that it could not tag the foo file. This is because CVS didn't remember what version it had after the rm. Well obvsiously cvs does remember the base revision of a locally removed file (1.3 in this case): 5:31 [1872] $ cvs status which.csh === File: no file which.csh Status: Locally Removed Working revision:-1.3Tue Jun 17 21:13:33 2003 Repository revision: 1.3 /cvs/master/m-NetBSD/main/src/usr.bin/which/Attic/which.csh,v Sticky Tag: netbsd-1-6 (branch: 1.3.12) Sticky Date: (none) Sticky Options: (none) The bug in cvs tag -F is that it just doesn't make use of that memory. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
[ On , January 27, 2005 at 12:07:39 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. Well, to tell the truth, all this tagging I do would be not an issue should CVS support changesets. The tagging in my use-cases is in fact an attempt to somehow mark a changeset to be able to retrieve it later (in a form of diff between two tags). CVS does support the concept of creating and managing sets of changes -- It just does not do so in the more general way you seem to think you want it to. Fundamentally in CVS every change set is the set of changes to the group of files committed by any given cvs commit command. Commits are more or less atomic and the combined commit log for each change set can be used to identify the change set. Abstract change sets which are unrelated to the fundamental change sets are created by using tags or branches. Branches are currently, IMO, the best way to manage arbitrary abstract change sets; and tags are second best, as you're discovering. However the most commonly used technique are those basic fundamental change sets inherently created by CVS with combined commits. Most of the free-OS projects that use CVS use this technique. NetBSD, for example, now has it down to a pretty much automated procedure and they've enhanced their commit-log generating script to include the exact CVS commands necessary to extract each change set on demand. See any of the recent commit log entries posted here for example: http://mail-index.NetBSD.org/source-changes/ These postings are then used by developers to identify change sets which are to be pulled up to a release branch. See this procedure docuemnted here: http://www.netbsd.org/developers/releng/pullups.html Note that I'm just a user of NetBSD, not one of the core developers. :-) Training your developers to work on one change at a time (per working directory), and to always commit everything involved in a given change with one single cvs commit command may not be so easy though, especially if they've grown too accustomed to other practices. In this case forcing them to put each unique change set on a unique branch will help. Of course using branches to manage change sets in a larger full SCM environment will require additional techniques and procedures, but how they are designed and implemented depends almost entirely on your specific local SCM goals and requirements. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 25, 2005, at 9:29 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: Paul had a case for desiring in certain cases to contact the server on add. Both cases _are valid_, my desire would be for add to contact the server only when an extra flag is passed. Well, I believe Paul case (lost productivity) is valid, but has nothing to do with 'cvs add', sorry. There is currently no way for CVS to force the user to run 'cvs add' as soon as he creates a file in the working copy anyway, so the user can be unaware about the problems for an undefined time period no matter how 'cvs add' is implemented. CVS doesn't have to force the user to run cvs add as soon as possible. But for those who religiously add files as soon as they create them, they won't have to wait to find errors that can be detected at add time. Those of you who prefer to wait to discover these errors can do so by postponing the adds as long as you like, and in fact my proposal allows for disabling the checks altogether at add time and catching them at commit time instead as CVS currently does. The whole point is to *enable* early detection of these kinds of problems for people who need the help, while letting those who don't care maintain their status quo. A large part of the CVS audience these days is in mixed-platform shops where naming conventions must be strictly enforced to maintain a smooth process end-to-end. These are the people who need the help, and it should not require an act of an admin and the possible loss of history to recover from a stupid mistake that could have been avoided early on. Logical continuation of Pauls' arguments leads me to the requirement for CVS to notice new/removed files/directories automatically making 'cvs add' and 'cvs remove' obsolete in the first place, not that I'm in favor of the latter. I'm afraid I don't see how this is a logical continuation of my arguments. I think it's unlikely that CVS will ever be able to second guess the user's intent when files appear or disappear in the workspace. The add and remove commands are clearly necessary to signal the introduction and abandonment of sources. I do believe that 'cvs -n commit' is the right way to check if the repository is willing to accept changes. If one needs functionality to check only additions and/or removals, then this functionality could be provided through 'cvs commit' so that it would be possible not only to check, but also to commit additions and/or removals only. This way Pauls' requested 'cvs add' functionality will be available through 'cvs -n commit -O add', provided the '-O add' means additions only. This is IMHO more logical and consistent than -C switch proposed for the 'cvs add'. So, to add a file, the user must: edit file cvs add file cvs -n commit file edit file cvs commit file Why not just skip the third step and run the check in one command? It's the addition of optional capability by adding to the command stream that makes clunky user interfaces. Things that are done together should be done in the same commands. Adding more command line options to the second command doesn't help, either, because it just makes the learning curve higher. It's a much simpler user model and implementation to just put in the add hook and edit .cvsrc to shut it off. That way, you set it once and forget it; you don't have to continually remember to run some arcane series of commands to do simple things. The other thing to consider here is that by adding the second command, you put responsibility of enforcing policy on the user, not on the tool. That opens up avenues for mistakes that are more natural than procedure. The proposal that I'm making prefers procedure while keeping the barrier low for those who believe that they can defeat it safely. Making changes to the working copy (be it editing existing files or adding/removing files/directories) and verifying these changes against the repository are separate activities. Let them continue to be different activities, please. You obviously view your toolset as a small collection of primitive tools that you can combine in arbitrary ways to cool and useful things. And when you say you want to this then all you need to do to this is that and that and the other thing, no problem. But then there's the other half of the users, who say All I want to do is this, and don't bother me with the details. All they want to do is accomplish some common task that happens to be what you consider to be two primitives. But since configuration management isn't interesting to them, they want one command to do what they want. Sure, it could be scripted, but then they to learn still more tools, which they won't do because they think the learning curve is too high. It's way easier to make the tool perform the sequences of actions that the user wants than to make the users remember every nuance of some tool they prefer not to use in the first
Re: CVS diff and unknown files.
[ On Wednesday, January 26, 2005 at 01:01:55 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. You're falling into the same trap that Greg does, which is to think that the way CVS works today is the way that it simply must work (except when he has an idea to make it better for himself). I agree that your use case points out another ugly wart in the way that CVS was designed and implemented. Well since I believe the design to be correct and the best possible for the goals and requirements, it's certinaly not an ugly wart. What would be ugly would be some all-knowing big-brother implementation that forced policy on everyone despite the fact that everyone's needs differ. (and I'm talking of course about multiple groups each with their own repositories, not multiple individuals using the same repo) If you want these kinds of policies then you can trivially implement them over and above the core cvs program using wrapper programs and/or scripts. Even your stupid register adds in the repo nonsense can be easily implemented by wrapper programs and a tiny registry on the server. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. Policy goes above -- it is not hard-coded in the core functionality. On Jan 25, 2005, at 9:29 AM, [EMAIL PROTECTED] wrote: Besides, concerning informing the user about problems ASAP, I find myself using 'cvs add' and 'cvs remove' as *late* as possible (as close to the commit as possible) due to the oddities in CVS behavior described below. Consider the following use-case where the intent of tagging is to mark the repository state just before committing of a set of changes that includes adding and/or removing of some files: $ cd working_copy $ echo a a $ cvs add a cvs server: scheduling file `a' for addition cvs server: use 'cvs commit' to add this file permanently [... time passes ... and now I'm ready to commit...] $ cvs update ... $ cvs tag -F before-my-changes cvs server: nothing known about a cvs [server aborted]: correct the above errors first! Oops! Need to remove file back to be able to tag the repository! Doesn't error nothing known about a look funny by the way? Shouldn't 'cvs update' show N meaning nothing known instead of A as the status of the file then :) No, CVS shouldn't say anything about the unknown file. The tag is being applied to the base revisions of the files in the working directory. A newly added, but uncommitted, file is simply like any other changed file in the working directory and the '-F' should ignore it just as it ignores the changes to files that are already in the repository. I.e. that is a bug, pure and simple. But consider this: All I want to do is tag my files before I commit them, and don't concern me with the detail. Okay, which versions do you want tagged, the ones that appear in your workspace when you did the update, or the ones that will appear in the repository when you commit? That's a nonsensical question. Tags can only be applied to revisions that are already in the repository. Tags applied with cvs tag always begin with the base revisions that the working directory was created with. However if you keep in mind that you cannot commit changes to out-of-date files, the silly dilema you pose proves to be even more nonsensical. (and if you want to tag specific revisions in the repository without respect to the state of any working directory then you would use cvs rtag for that) The tag command should be changed to do what you want and expect, not to force you into some bogus sequence of commands just to satisfy the tool. The cvs tag and cvs rtag commands can already do exactly what he wants, and what he expects -- and the ordering of commands is not bogus, but rather a clear and obvious progression of steps. Things have to be done in the proper order. You can't commit changes you haven't made yet, for example. Somewhat similar problem exists with 'cvs remove' (here the problem is even harder to avoid as 'cvs update' re-creates missing files not marked with 'cvs remove'): $ rm b # don't need this file anymore $ cvs remove b # need this to prevent 'update' from re-creating it. cvs server: scheduling `b' for removal cvs server: use 'cvs commit' to remove this file permanently [... time passes ... and now I'm ready to commit...] $ cvs update ... $ cvs tag -F before-my-changes cvs server: Tagging . cvs server: skipping removed but un-commited file `b' Oops! Need to undo the 'cvs remove' of the file to be able to correctly tag it in the repository. Again, this is a human factors issue that wasn't well considered when CVS was designed. No, this one is a bug, pure and simple. The uncommitted remove
Re: CVS diff and unknown files.
On Jan 26, 2005, at 11:06 AM, [EMAIL PROTECTED] wrote: [ On Wednesday, January 26, 2005 at 01:01:55 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. You're falling into the same trap that Greg does, which is to think that the way CVS works today is the way that it simply must work (except when he has an idea to make it better for himself). I agree that your use case points out another ugly wart in the way that CVS was designed and implemented. Well since I believe the design to be correct and the best possible for the goals and requirements, it's certinaly not an ugly wart. Okay, so we're in violent agreement on that small point! :-) What would be ugly would be some all-knowing big-brother implementation that forced policy on everyone despite the fact that everyone's needs differ. (and I'm talking of course about multiple groups each with their own repositories, not multiple individuals using the same repo) Agreed. If you want these kinds of policies then you can trivially implement them over and above the core cvs program using wrapper programs and/or scripts. Even your stupid register adds in the repo nonsense can be easily implemented by wrapper programs and a tiny registry on the server. What register adds in the repo nonsense are you talking about? The proposal I made simply requires a contact with the server to run the add-time triggers; it does NOT require add-time modifications of the repository by the CVS server itself. If the triggers drop turds in the repository, then that's a different matter. Also remember that my proposal includes a way to shut off the add-time triggers as a client configuration, deferring them to commit time to accommodate users like you. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. I had hoped that this was clear in the last go-round, but apparently not. Policy goes above -- it is not hard-coded in the core functionality. Agreed. But the tool must be sufficiently flexible to allow robust implementations of policies. Sometimes triggers are the right way (and wrapper scripts are not), and we've identified one area here where CVS is not sufficiently flexible. On Jan 25, 2005, at 9:29 AM, [EMAIL PROTECTED] wrote: Besides, concerning informing the user about problems ASAP, I find myself using 'cvs add' and 'cvs remove' as *late* as possible (as close to the commit as possible) due to the oddities in CVS behavior described below. Consider the following use-case where the intent of tagging is to mark the repository state just before committing of a set of changes that includes adding and/or removing of some files: $ cd working_copy $ echo a a $ cvs add a cvs server: scheduling file `a' for addition cvs server: use 'cvs commit' to add this file permanently [... time passes ... and now I'm ready to commit...] $ cvs update ... $ cvs tag -F before-my-changes cvs server: nothing known about a cvs [server aborted]: correct the above errors first! Oops! Need to remove file back to be able to tag the repository! Doesn't error nothing known about a look funny by the way? Shouldn't 'cvs update' show N meaning nothing known instead of A as the status of the file then :) No, CVS shouldn't say anything about the unknown file. The tag is being applied to the base revisions of the files in the working directory. A newly added, but uncommitted, file is simply like any other changed file in the working directory and the '-F' should ignore it just as it ignores the changes to files that are already in the repository. I.e. that is a bug, pure and simple. But consider this: All I want to do is tag my files before I commit them, and don't concern me with the detail. Okay, which versions do you want tagged, the ones that appear in your workspace when you did the update, or the ones that will appear in the repository when you commit? That's a nonsensical question. Tags can only be applied to revisions that are already in the repository. Tags applied with cvs tag always begin with the base revisions that the working directory was created with. Remember, I take a user-centric view of the world when I discuss CVS. It's frequently said to users that tags apply to the versions in your workspace when cvs tag is used. But after
Re: CVS diff and unknown files.
Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote: [...] Is there any sound reason why 'cvs add' and 'cvs remove' commands require *write* access to the repo? I believe what Paul means, is that no one has yet owned up to writing or submitted the patches to implement the changes. Please see the linked thread to answer your question. Greg I believe there is no need in the normal case for add to contact the repo, especially to write, unfortunately it is currently implemented to connect. Paul had a case for desiring in certain cases to contact the server on add. Both cases _are valid_, my desire would be for add to contact the server only when an extra flag is passed. http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=add+hook+question+%28wassubmit=Search%21idxname=info-cvsmax=20result=normalsort=date%3Aearly http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00150.html http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00188.html the trick I showed you is the fake I was speaking of in: http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00191.html Please understand the linked thread before posting much on this, as the heat got kind of high the last time we discussed it. Thanks a lot for the links, -- I'll study them. I have no intention to raise the heat on this issue even higher indeed. So, this particular issue aside for now and returning to the initial problem, aren't there any proposals/suggested patches to add an option to the 'cvs diff' to include unknown files into the output the same way it now includes locally added but not committed files? Does such extension somehow interferes with the cvs way of doing things? -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote: SNIP It's unclear if that particular change will be made, or if made whether or not it will stay. The requirement to supply add-time triggers has been identified (by a number of users), which requires a contact with the server. This has undergone some heated debate. Well, the problem described is in fact not in contacting with server, but in requiring write access to the repository. Is there any sound reason why 'cvs add' and 'cvs remove' commands require *write* access to the repo? I believe what Paul means, is that no one has yet owned up to writing or submitted the patches to implement the changes. Please see the linked thread to answer your question. Wow! Nice discussion indeed! I'm sorry I somehow missed it (apparently thinking that it's yet another discussion about cvs import that IMHO is hopelessly broken for the purpose of tracking third-party sources albeit CVS manual suggest otherwise). Greg I believe there is no need in the normal case for add to contact the repo, especially to write, unfortunately it is currently implemented to connect. I'm another one here who believes Greg and you are right. Paul had a case for desiring in certain cases to contact the server on add. Both cases _are valid_, my desire would be for add to contact the server only when an extra flag is passed. Well, I believe Paul case (lost productivity) is valid, but has nothing to do with 'cvs add', sorry. There is currently no way for CVS to force the user to run 'cvs add' as soon as he creates a file in the working copy anyway, so the user can be unaware about the problems for an undefined time period no matter how 'cvs add' is implemented. Logical continuation of Pauls' arguments leads me to the requirement for CVS to notice new/removed files/directories automatically making 'cvs add' and 'cvs remove' obsolete in the first place, not that I'm in favor of the latter. I do believe that 'cvs -n commit' is the right way to check if the repository is willing to accept changes. If one needs functionality to check only additions and/or removals, then this functionality could be provided through 'cvs commit' so that it would be possible not only to check, but also to commit additions and/or removals only. This way Pauls' requested 'cvs add' functionality will be available through 'cvs -n commit -O add', provided the '-O add' means additions only. This is IMHO more logical and consistent than -C switch proposed for the 'cvs add'. Making changes to the working copy (be it editing existing files or adding/removing files/directories) and verifying these changes against the repository are separate activities. Let them continue to be different activities, please. In my point of view, the optimal CVS behavior is the following: 1. Neither 'cvs add' nor 'cvs remove' ever contact repository (-C aside, see below). 2. To check if the changes are OK without actually committing them, including addition and removal of files, 'cvs -n commit' should be used. 3. -O (add|remove|change) option could be implemented in 'cvs commit' if somebody finds enough sense in it (I don't). 4. Provided -O is implemented, -C option for add (and remove) could then be implemented to be semantically the same as running 'cvs add files' followed by 'cvs -n commit -O add files'. I.e., it will warn about the problems, not prevent the operation. [By the way, why is it -C, and not -c? There is similar option for cvs tag called -c] Besides, concerning informing the user about problems ASAP, I find myself using 'cvs add' and 'cvs remove' as *late* as possible (as close to the commit as possible) due to the oddities in CVS behavior described below. Consider the following use-case where the intent of tagging is to mark the repository state just before committing of a set of changes that includes adding and/or removing of some files: $ cd working_copy $ echo a a $ cvs add a cvs server: scheduling file `a' for addition cvs server: use 'cvs commit' to add this file permanently [... time passes ... and now I'm ready to commit...] $ cvs update ... $ cvs tag -F before-my-changes cvs server: nothing known about a cvs [server aborted]: correct the above errors first! Oops! Need to remove file back to be able to tag the repository! Doesn't error nothing known about a look funny by the way? Shouldn't 'cvs update' show N meaning nothing known instead of A as the status of the file then :) Somewhat similar problem exists with 'cvs remove' (here the problem is even harder to avoid as 'cvs update' re-creates missing files not marked with 'cvs remove'): $ rm b # don't need this file anymore $ cvs remove b # need this to prevent 'update' from re-creating it. cvs server: scheduling `b' for removal cvs server: use 'cvs commit' to remove
Re: CVS diff and unknown files.
[ On Saturday, January 22, 2005 at 18:59:33 (-0800), Mark D. Baushke wrote: ] Subject: Re: CVS diff and unknown files. cvs add does not (and must not :-) contact the server. When I use mkdir foo cvs add foo it contacts the server and creates the directory on the remote reposiotry using either the current stable or feature releases of CVS. Hmmm... yes, of course. I was of course thinking of the desired behaviour and of a few tiny but inappropriate hacks I've made to my local version to work around this problem until such time as the desired behaviour becomes the norm. Sorry for the confusion! ;-) FYI I couldn't send mail directly to you [EMAIL PROTECTED] anyway. Your DNS is broken and now you're also listed at bogusmx.rfc-ignorant.org: $ host -v -t mx javad.ru Query about javad.ru for record types MX Query for MX records done, 1 answer, status: no error The following answer is not authoritative: Answer section contains (1 record): javad.ruIN MX 10 mailhost.javad.ru Checking if mailhost.javad.ru is a canonical hostname ... mailhost.javad.ru IN CNAME ns.javad.ru ns.javad.ru IN A 62.105.138.7 *** javad.ru MX host mailhost.javad.ru is not canonical -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 21, 2005 at 20:06:37 (+0300), [EMAIL PROTECTED] wrote: ] Subject: CVS diff and unknown files. Is there a way to include contents of unknown files into the 'cvs diff' output? I did try the -N switch but it doesn't seem to do the trick. You must cvs add the files before they can be seen as new. I can't 'cvs add' the files as the repository is read-only for me (public read-only repository of an open-source project). Yes, you can, or at least you should be able to. cvs add does not (and must not :-) contact the server. Well, it does :( : $ echo dummy dummy.txt $ cvs add -m dummy.txt cvs [server aborted]: add requires write access to the repository -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Sergei Organov wrote: Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 21, 2005 at 20:06:37 (+0300), [EMAIL PROTECTED] wrote: ] Subject: CVS diff and unknown files. Is there a way to include contents of unknown files into the 'cvs diff' output? I did try the -N switch but it doesn't seem to do the trick. You must cvs add the files before they can be seen as new. I can't 'cvs add' the files as the repository is read-only for me (public read-only repository of an open-source project). Yes, you can, or at least you should be able to. cvs add does not (and must not :-) contact the server. Well, it does :( : $ echo dummy dummy.txt $ cvs add -m dummy.txt cvs [server aborted]: add requires write access to the repository Until the Fix that Greg described late last year is put in, you can (I think) trick cvs at least for files. ***begin cvs_trick_add #! /bin/bash echo /$1/0/dummy timestamp// CVS/Entries echo cvs trick added $1 to the Entries file. ***end cvs_trick_add cvs_trick_add dummy.txt -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Todd Denniston [EMAIL PROTECTED] writes: [...] $ echo dummy dummy.txt $ cvs add -m dummy.txt cvs [server aborted]: add requires write access to the repository Until the Fix that Greg described late last year is put in, you can (I think) trick cvs at least for files. ***begin cvs_trick_add #! /bin/bash echo /$1/0/dummy timestamp// CVS/Entries echo cvs trick added $1 to the Entries file. ***end cvs_trick_add cvs_trick_add dummy.txt Thanks a lot for the trick, Todd! Though I usually try to avoid temptation to edit CVS/ files manually, it seems that in this case it's indeed easier than replicating of the whole project into another directory and using regular 'diff' to compare them. Glad to hear things are going to be changed in the (hopefully near) future. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: [...] $ echo dummy dummy.txt $ cvs add -m dummy.txt cvs [server aborted]: add requires write access to the repository Until the Fix that Greg described late last year is put in, you can (I think) trick cvs at least for files. ***begin cvs_trick_add #! /bin/bash echo /$1/0/dummy timestamp// CVS/Entries echo cvs trick added $1 to the Entries file. ***end cvs_trick_add cvs_trick_add dummy.txt Thanks a lot for the trick, Todd! Though I usually try to avoid temptation to edit CVS/ files manually, it seems that in this case it's indeed easier than replicating of the whole project into another directory and using regular 'diff' to compare them. Glad to hear things are going to be changed in the (hopefully near) future. It's unclear if that particular change will be made, or if made whether or not it will stay. The requirement to supply add-time triggers has been identified (by a number of users), which requires a contact with the server. This has undergone some heated debate. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Paul Sander [EMAIL PROTECTED] writes: On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: [...] $ echo dummy dummy.txt $ cvs add -m dummy.txt cvs [server aborted]: add requires write access to the repository Until the Fix that Greg described late last year is put in, you can (I think) trick cvs at least for files. ***begin cvs_trick_add #! /bin/bash echo /$1/0/dummy timestamp// CVS/Entries echo cvs trick added $1 to the Entries file. ***end cvs_trick_add cvs_trick_add dummy.txt Thanks a lot for the trick, Todd! Though I usually try to avoid temptation to edit CVS/ files manually, it seems that in this case it's indeed easier than replicating of the whole project into another directory and using regular 'diff' to compare them. Glad to hear things are going to be changed in the (hopefully near) future. It's unclear if that particular change will be made, or if made whether or not it will stay. The requirement to supply add-time triggers has been identified (by a number of users), which requires a contact with the server. This has undergone some heated debate. Well, the problem described is in fact not in contacting with server, but in requiring write access to the repository. Is there any sound reason why 'cvs add' and 'cvs remove' commands require *write* access to the repo? -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Sergei Organov writes: Is there any sound reason why 'cvs add' and 'cvs remove' commands require *write* access to the repo? CVS add of a directory modifies the repository, but I suspect the actual motivation was the principle that you should tell someone that they're not allowed to do what they're trying to do as soon as possible rather than as late as possible. -Larry Jones Philistines. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote: SNIP It's unclear if that particular change will be made, or if made whether or not it will stay. The requirement to supply add-time triggers has been identified (by a number of users), which requires a contact with the server. This has undergone some heated debate. Well, the problem described is in fact not in contacting with server, but in requiring write access to the repository. Is there any sound reason why 'cvs add' and 'cvs remove' commands require *write* access to the repo? I believe what Paul means, is that no one has yet owned up to writing or submitted the patches to implement the changes. Please see the linked thread to answer your question. Greg I believe there is no need in the normal case for add to contact the repo, especially to write, unfortunately it is currently implemented to connect. Paul had a case for desiring in certain cases to contact the server on add. Both cases _are valid_, my desire would be for add to contact the server only when an extra flag is passed. http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=add+hook+question+%28wassubmit=Search%21idxname=info-cvsmax=20result=normalsort=date%3Aearly http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00150.html http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00188.html the trick I showed you is the fake I was speaking of in: http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00191.html Please understand the linked thread before posting much on this, as the heat got kind of high the last time we discussed it. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
[ On , January 21, 2005 at 20:06:37 (+0300), [EMAIL PROTECTED] wrote: ] Subject: CVS diff and unknown files. Is there a way to include contents of unknown files into the 'cvs diff' output? I did try the -N switch but it doesn't seem to do the trick. You must cvs add the files before they can be seen as new. I can't 'cvs add' the files as the repository is read-only for me (public read-only repository of an open-source project). Yes, you can, or at least you should be able to. cvs add does not (and must not :-) contact the server. -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Greg, Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 21, 2005 at 20:06:37 (+0300), [EMAIL PROTECTED] wrote: ] Subject: CVS diff and unknown files. Is there a way to include contents of unknown files into the 'cvs diff' output? I did try the -N switch but it doesn't seem to do the trick. You must cvs add the files before they can be seen as new. I can't 'cvs add' the files as the repository is read-only for me (public read-only repository of an open-source project). Yes, you can, or at least you should be able to. cvs add does not (and must not :-) contact the server. When I use mkdir foo cvs add foo it contacts the server and creates the directory on the remote reposiotry using either the current stable or feature releases of CVS. In addition, I believe you will find that a 'cvs add' for a normal file will also contact the server in order to create a CVS/Entries entry for the new file with a '0' version and a 'dummy timestamp' as well. While it has been proposed that this behavior should be changed, no change to this behavior has been committed to the CVS sources as yet. So, even if it 'must not' exhibit this behavior, it does appear to exhibit it at present. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB8xMV3x41pRYZE/gRApXyAJ0b1C6NFGM/XEGtZ8phZMGlwYqCFwCgpPR+ yD54uze0jmtHqDuyf0AfYu0= =q+NZ -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
CVS diff and unknown files.
Hi, Is there a way to include contents of unknown files into the 'cvs diff' output? I did try the -N switch but it doesn't seem to do the trick. I can't 'cvs add' the files as the repository is read-only for me (public read-only repository of an open-source project). Thanks in advance. -- Sergei. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
