Re: 'cvs add' client/server semantics (was Re: Triggers)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander <[EMAIL PROTECTED]> writes: > 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. I find that concrete examples are useful... Does this one illustrate the usefulness your suggested change? Consider a shop which has a majority of folks using either UNIX or Windows clients as their primary development base. A file exists the mymodule/directory called 'MyFoo.h,v' and the local policy is that once a file has been added to the repository, no new file that a difference only in the case of the filename may be committed to that directory should be different only in case. So, the addition of a file named 'myfoo.h' to the directory should be allowed. The commitinfo will make this check as a part of the policy. If there were triggers for 'cvs add', then those triggers could notify the user that adding 'myfoo.h' conflicts with the existing 'MyFoo.h' which would possibly stop a lot of modifications that '#include "myfoo.h"' from doing the wrong thing that would otherwise only be caught by the 'cvs commit' triggers later. In this case, a UNIX user may have forgotten that when a windows user checks out 'MyFoo.h' there is no room for a new 'myfoo.h' to exist in the same directory. It is also possible that the 'policy' being enforced would be that no mixed-case .h files should live in such a directory, so that only 'myfoo.h' would be allowed to be added in the first place. Now, I will grant that it is certainly possible for a user to 'fix' their checked out tree to work around this problem. However, it may be desirable to get it right the first time rather than waste time later. However, I am not sure how this argument for an advisory trigger at 'cvs add' time which then becomes a manditory 'enforcement trigger' at commit time would not also be potentially very confusing to the users. At present, it is clear from both sides that the 'cvs add' behavior is broken. I have probably missed some of the points, but let me try to summarize: - a new directory that is added with 'cvs add' does not go thru any peremptory enforcement checks at all (a cvs add trigger OR a policy that cvs add is a local-only operation would partially fix this provided that some other trigger addressed the creation of a new directory in the repository). - related to this, the 'cvs import' functionality is likewise 'broken' as it currently may stomp on existing tags and could create files and directories that are not acceptable to an administrators policies. There are presently no enforcer triggers that prevent a particular user from doing an import into the repository. - there are good reasons for both 'cvs add' and 'cvs rm' to be considered as local operations that should not contact the server: a) allows read-only users to generate 'cvs diff -N' output to send to a maintainer b) lets the local user experiment with re-oranization of the hierarchy of a module. (It is unclear if there would be any easy way to 'rename' files in the local tree and resolve them in a reasonble manner with the cvs server at a later date.) c) allows a user to continue to do useful work even when access to the server is unavailable (it might be down for maintenance, or the user may be working from a disconnected network). - there are good reasons for 'cvs add' to have an advisory process (which becomes an enforcement at cvs commit time) a) inform the user early that a proposed addition will fail at such a time that the user does a 'cvs commit' so as to minimize the amount of work that is done under a mistaken assumption that the commit would succeed. b) provide for a simpler kind of trigger implementation to just implement policy on newly created files at commit time. c) the addition of pre- and post- triggers to cvs commands that presently modify the repository allows more control for a cvs administrator to enforce policy pro-actively. If the 'cvs add' commands continues to allow modification of the repository (creation of new directories), then there needs to be a way to catch abuses of policy. So, it comes down to a choice of how should the 'cvs add' command operate going forward and where is the correct place to add 'enforcer' triggers for the administration of a repository. I am finding Paul's arguments for additional flexibili
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 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 sugges
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 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
Re: RV: Newbie question. How to manage replaced files
N?stor Bosc?n <[EMAIL PROTECTED]> wrote: > > I have been using CVS for some time and have encounter problems when > somebody gives me a file that I have to replaced in my CVS sandbox. This > always happens because sometimes I have people outside the organization and > they send new versions of files that I have to replace in the sandbox and > try to update and commit to the CVS Repository. What is the best way to > manage this case? I would figure out what revision of the file the external user started with. Then I would create a branch at that revision, commit the modification to that branch and see if I can merge the branch back to the trunk. By extension, if people send you patch of the entire source tree, *based on a released version*, you can branch the entire tree off the corresponding release tag, apply the patch, commit, and decide whether you want to merge the branch. If you can't determine the revision or tag from which to branch, you probably need to tighten your controls a little... -- pa at panix dot com ___ 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
Fedora 2, xinetd problem: connection refused
Hi, I've been struggling this for two days now, seems all is done correctly,
but somehow it still doesn't work. I'm trying to setup CVS (version 1.11.17
in Fedora 2) to allow remote pserver access. It all works fine locally, but
I couldn't get xinetd to listen on 2401, symptoms:
(1) when I telnet to 2401, I got "Could not open connection to the host, on
port 2401: connection failed"
(2) If I do "cvs -d:pserver:[EMAIL PROTECTED]/tar/cvsroot/ login", I got
"cvs [login aborted]: connect to 192.168.51.10(192.168.51.10):2401 failed:
Connection refused"
(3) If I do "chkconfig --list", it lists "cvspserver on" as services uner
xinted
(4) iptables is empty
I've done the following:
(1) added cvspserver to /etc/xinet.d/ that contains:
service cvspserver
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= root
env = HOME=/var/cvsroot
passenv =
server = /usr/bin/cvs
server_args = --allow-root=/var/cvsroot pserver
}
(2) /etc/services does contain "cvspserver2401/tcp" and for udp.
(3) restarted xinet.d with /etc/init.d/xinetd restart
I couldn't think of anything that will prevent the service on port 2401, any
suggestions? I'm
completely lost at the moment. Really appreciate it.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
RV: Newbie question. How to manage replaced files
Hi I have been using CVS for some time and have encounter problems when somebody gives me a file that I have to replaced in my CVS sandbox. This always happens because sometimes I have people outside the organization and they send new versions of files that I have to replace in the sandbox and try to update and commit to the CVS Repository. What is the best way to manage this case? Regards, Néstor Boscán ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to use cvs with a group of users and restrictive file perms
Martin Heinen wrote: > CVS shouldn't be used to install files. Instead, install > the files with a different tool such as a Makefile or a > script and use CVS to manage the additional files. > > If you want to restrict access to checked out copies, use > the tools of your operating system (e.g., umask on UNIX systems). The problem is that the checkout usually gets rdisted to many systems... make wouldn't be a good solution since It would mean to create a temporary to-rdist-tree and handling all the special chmod cases (one file has that modes, an other file has other modes - everything as restrictive as possible) It would complicate the whole thing if you have to create a "filename - mode" mapping table. In regard of others I've to KISS. Is there no other way? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to use cvs with a group of users and restrictive file perms
On Sun, Jan 30, 2005 at 03:30:00PM +0100, Oliver Lehmann wrote: > I would like to use cvs with a group of users. That fact alone is quiet > easy to handle by doing what https://ccvs.cvshome.org/fom/cache/92.html > says. The problem I have is, that the files I want to manage with cvs are > having restrictive permissions like 0700 and so on. cvs adjusts those > permissions and when I checkout the files I get 0755 for example (like the > directory has where thoses files are stored in - group-setuid mode). > That is really bad is there a way to tell cvs that I want my files > with a special mode checked out? Or do you see any other ways of how to > handle this? CVS shouldn't be used to install files. Instead, install the files with a different tool such as a Makefile or a script and use CVS to manage the additional files. If you want to restrict access to checked out copies, use the tools of your operating system (e.g., umask on UNIX systems). -- Marxpitn ___ 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.)
[...] 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
How to use cvs with a group of users and restrictive file perms
Hi, I would like to use cvs with a group of users. That fact alone is quiet easy to handle by doing what https://ccvs.cvshome.org/fom/cache/92.html says. The problem I have is, that the files I want to manage with cvs are having restrictive permissions like 0700 and so on. cvs adjusts those permissions and when I checkout the files I get 0755 for example (like the directory has where thoses files are stored in - group-setuid mode). That is really bad is there a way to tell cvs that I want my files with a special mode checked out? Or do you see any other ways of how to handle this? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ 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 d
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 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, b
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
