Re: 'cvs add' client/server semantics (was Re: Triggers)
On Feb 5, 2005, at 12:47 PM, [EMAIL PROTECTED] wrote: [ On Thursday, February 3, 2005 at 00:29:31 (-0800), Paul Sander wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) Many shops seem to think that it's reasonable to allow users to commit code only after it has successfully compiled. In fact I happen to agree with that partciular policy and I try to follow it as well as I can even on my private projects. However just because a new file appears doesn't mean it's immediately going to be used in the build -- quite the opposite as it normally won't, at least not with any sane build system I would use. I.e. your argument about not immediately committing new, but probably still empty, files is, still, a complete and total straw man. Please try to think a little about these things. Your answer was the kind of automaton-like regurgitation of a simplistic rule which I would only have expected from a computer following an ill-conceived and overly-strict recipe -- or maybe a manager who doesn't actually know how to do the job himself. :-) Some shops rely heavily on autodiscovery in their build systems, and consider it feature. Some shops don't permit committing dead files to an active source base, either, whether it be because they're brand new or because their APIs have just been disconnected from the rest of the system. Please try to open up to disciplines that you have not directly experienced yourself. And you need to start to acknowledge that these are viable approaches to certain problems, even if they're not the specific ones you would choose. Right or wrong, good or bad, these are real world experiences. Perhaps, but I want the option to ask it if it foresees any problems with my actions. If you don't like it, don't use it. I didn't say you couldn't have such an "option" -- in fact you already have it, in spades. Okay, let me be more clear: I want the "cvs add" command to give me the option. There's a reason why it needs to be there, even if you refuse to acknowledge it. There are an almost infinite number of ways for you to ask if a new filename is acceptable and not one of them requires any change of any kind to the core CVS program. And most of them require much more work to work around the absence of the capability in CVS than to implement it directly. Many of those possible ways don't even require software implementations. CVS is not a substitute for management, nor a substitute for developer communication, nor does it have a built-in process model. And these are all good things for it not to have too! I agree that CVS shouldn't have this stuff hard-coded into it. However, it's crucial that it have the necessary hooks to integrate with the tools that perform those functions. This is one of the reasons why I maintain that CVS remains a toy system, suitable for managing toy or immature development efforts. If your project requires strict file naming rules be followed then you need to invent procedures and processes to help meet that requirement but you should not even expect to look to CVS for help here. The very fact that you do suggests you think CVS is, or should be, something that it is not. That said you can in fact still implement technical controls that can mandate a requirement like strict file naming rules, IFF you do it through commitinfo scripting hooks. If that's not sufficient for your needs then CVS is not the right tool for (this part of) your project. After two weeks are arguing, you still don't get that the very best time to check a file's name is at the moment it's created. Sigh. Your loss. -- 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 add' client/server semantics (was Re: Triggers)
[ On Thursday, February 3, 2005 at 00:29:31 (-0800), Paul Sander wrote: ] > Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) > > > Many shops seem to think that it's reasonable to allow users to commit > code only after it has successfully compiled. In fact I happen to agree with that partciular policy and I try to follow it as well as I can even on my private projects. However just because a new file appears doesn't mean it's immediately going to be used in the build -- quite the opposite as it normally won't, at least not with any sane build system I would use. I.e. your argument about not immediately committing new, but probably still empty, files is, still, a complete and total straw man. Please try to think a little about these things. Your answer was the kind of automaton-like regurgitation of a simplistic rule which I would only have expected from a computer following an ill-conceived and overly-strict recipe -- or maybe a manager who doesn't actually know how to do the job himself. :-) > Perhaps, but I want the option to ask it if it foresees any problems > with my actions. If you don't like it, don't use it. I didn't say you couldn't have such an "option" -- in fact you already have it, in spades. There are an almost infinite number of ways for you to ask if a new filename is acceptable and not one of them requires any change of any kind to the core CVS program. Many of those possible ways don't even require software implementations. CVS is not a substitute for management, nor a substitute for developer communication, nor does it have a built-in process model. And these are all good things for it not to have too! If your project requires strict file naming rules be followed then you need to invent procedures and processes to help meet that requirement but you should not even expect to look to CVS for help here. The very fact that you do suggests you think CVS is, or should be, something that it is not. That said you can in fact still implement technical controls that can mandate a requirement like strict file naming rules, IFF you do it through commitinfo scripting hooks. If that's not sufficient for your needs then CVS is not the right tool for (this part of) your project. -- 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 add' client/server semantics (was Re: Triggers)
On Feb 2, 2005, at 12:53 PM, [EMAIL PROTECTED] wrote: [ On Wednesday, February 2, 2005 at 03:35:48 (-0800), Paul Sander wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) Committing empty files may not be permitted by project policy. Straw man! (and a B.S. policy if I've ever seen one!) Many shops seem to think that it's reasonable to allow users to commit code only after it has successfully compiled. I happen to think it's a bogus policy, too, but then the shops that employ such policies have no appreciation of good change control and they think that this is a method that's "good enough". Unfortunately, my experience has been that cussing at it doesn't make it go away. No, I don't really want total control over all client operations. But I would like more opportunities for the server to say "no". "cvs add" (and "cvs rm") operations DO NOT EVER CONCERN THE SERVER. Period. Perhaps, but I want the option to ask it if it foresees any problems with my actions. If you don't like it, don't use it. -- 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 add' client/server semantics (was Re: Triggers)
[ On Wednesday, February 2, 2005 at 03:35:48 (-0800), Paul Sander wrote: ] > Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) > > Committing empty files may not be permitted by project policy. Straw man! (and a B.S. policy if I've ever seen one!) > No, I don't really want total control over all client operations. But > I would like more opportunities for the server to say "no". "cvs add" (and "cvs rm") operations DO NOT EVER CONCERN THE SERVER. Period. They are simply the required alternatives to using an editor to change an existing file in the working directory. CVS is not psychic -- you have to tell it what you mean. > That's an exaggeration. I really don't want to control every > keystroke. I just want to keep them on the path they've agreed to > take, because it's easier to stay there than to wander off and find the > way back. Same difference. -- 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 add' client/server semantics (was Re: Triggers)
On Feb 1, 2005, at 12:47 PM, [EMAIL PROTECTED] wrote: [ On Sunday, January 30, 2005 at 22:24:06 (-0800), Mark D. Baushke wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) - 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. Those two are logically the exact same "reason" (the first is just a specific form of the second), but neither are valid for CVS: The user has the option of doing an immediate "cvs commit" of an empty file if he or she wants to know if the filename is acceptable to the repository. The core CVS program must not force these kinds of timing decisions on the user. Besides t If a shop wants to enforce this kind of policy with some kind of technical control then they have the option of writing a wrapper program that has a "create file" feature which will create an empty file, "cvs add" it, and then immediately "cvs commit" it. A shop also has the option of writing their own CVS client that combines the "cvs add" and "cvs commit" operations into one so that a file must always be immediately commited (even if empty, just to reserve the name). Committing empty files may not be permitted by project policy. Many shops don't permit committing files until the code compiles. (This is not a policy I agree with, but I have seen it in my shops. The theory is that anyone should be able to get working code from any update, but I think there are better methods.) A shop also has the option of writing wrappers, or alternate client programs, that use other repository server programs to check repo policies at "cvs-wrapper add" time. And this is better, cheaper, faster than adding the capability to CVS in what way? (Yeah, yeah, yeah, because it wasn't Given that proposed add-time triggers are optional on both the client and server side, the argument is vacuous.) None of the above require any server contact to be done in the core CVS program within its basic "cvs add" function -- they can all be done externally in those few places where someone might think they are necessary. Given that the proposed add-time trigger is optional and reverts to what you call CVS' "basic cvs add function", the fact that triggers can be done elsewhere does not necessarily mean that they should be. 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. This kind of nonsense goes way beyond the basic change tracking functionality of CVS and tries to turn CVS into a project management tool. Such things are best done by additional tools since they have an extremely narrow application in a very limited number of shops. No, it does not try to turn CVS into a project management tool. It enables CVS to integrate with one. There's a difference, and I find that tightly integrated environment tend to work better. By "tightly integrated" I mean a collection of tools that freely exchange data in meaningful ways and spawn or sense actions taken in other tools. The *info scripting hooks in CVS are only intended to make site customization possible for things like reporting functions, and to provide hooks for for very basic consistency checks. CVS is supposed to keep out of your way, not get in your face at every point you interact with it. Ah, this statement suggest that you believe that policies are serving and that automatic enforcement serves only to hinder progress. In my experience, the best policies have the following qualities: - Understood and agreed upon by the entire team. - Automated to the full extent possible. - Tedious tasks are fully automated. - Default tool settings produce proper results. - Errors are detected as early as is practical, while they're easy to fix. - Error correction is not hindered. - Users produce correct results, unaware that policies are in fact being enforced. In the end, the right product pops out the end of the process, with an acceptable level of quality, almost as a natural consequence (or even side-effect). Certainly he is not suggesting any client/server protocol change and the addition of a trigger is very simple to accomplish. Well actually he is requiring a protocol change -- at least if it's to be done right. And remember he'd likely also want "cvs rm" triggers. I have
Re: 'cvs add' client/server semantics (was Re: Triggers)
[ On Monday, January 31, 2005 at 08:05:47 (-0800), Mark D. Baushke wrote: ] > Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) > > If I move 'foo.c' to 'bar.c' the CVS/Entries file is going to be confused. > > In general, doing lots of bulk renaming and local 'cvs add' and 'cvs rm' > operations without contacting the repository could be useful in some > situations, but could be very confusing as well. Indeed -- people (CVS users in particular :-) need to stop thinking in terms of "rename" and go back to the good old fundamental underlying concepts of creation and deletion. There is no such thing as a "rename" in most facets of computing. Even in the filesystem there's no such thing as a "rename". There's a rename() system call in all modern systems, but it just makes a link() & unlink() with appropriate locking to prevent clashes and so that it appears as one operation; Fundamentally it's still a link() followed by an unlink() and no amount of wiggling and worming with the English language can change that. For example if the power to the system is cut exactly in the middle of a rename() execution then both files might exist after a reboot, or the old file might have to be relinked by a filesystem consistency checker. However with any stable and reliable filesystem implementation that guarantees metadata consistency once the rename() call returns then only the new filename exists, and even if the power is cut immediately after the return completes all will be well after a reboot (with that filename, at least). I.e. an application calling rename() can be sure the link() & unlink() have both completed successfuly and securely once the rename() returns successfully. That's the only reason for making a combined meta-operation like link() and unlink() into a separate system call. CVS can implement a form of "atomic" rename too if the user is careful to always commit after each "mv a b; cvs rm a; cvs add b" sequence. Sites with untrained and/or careless users should probably use a wee tiny wrapper script to simplify this sequence for those users though (i.e. to emulate the OS rename() system call :-) Someone might someday even enhance the standard CVS client so that it can do all four operations in one sequence and to also create a uniform standard log message too so that reporting tools can sort out exactly what happened just by looking at the commit logs. If I were to implement such a meta-command I would only allow one pair of normal filenames to be specified so that each file rename would have to be done individually; but it is conceivable that someone else might even implement it so that it could combine all the sequences for all the files in a whole directory so that even a directory could "appear" to be renamed with one simple command. Such an implementation would just be a convenience feature though and the same underlying command sequences could still be issued independently by the user. -- 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 add' client/server semantics (was Re: Triggers)
[ On Monday, January 31, 2005 at 01:18:36 (-0800), Paul Sander wrote: ] > Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) > > 'Course, Greg has claimed in the past that he already has a patch... Actually, no, I have never made any such claim. I've posted everything I have done so far save for a few tiny hacks that are incomplete and inappropriate for general use. > I have some questions for Greg regarding his patch: Assume the > repository contains a directory tree foo/bar. Both directories contain > files. The user performs the following sequence of commands: > > cvs checkout -l foo > cd foo > mkdir bar > cvs add bar > cd bar > > At this point, is the workspace in a state in which the user can > successfully invoke the "cvs add" and "cvs update" commands on new and > existing files contained by the bar directory, before the next commit? Well yes, I should certainly hope so. The first command should have created a "D" entry for the "bar" directory in the CVS/Entries file even though that directory was not initially created in the local workspace. This doesn't happen with the current implementation, but it probably should. Doing this may require cleaning up and adjusting some internal error checking in the client too, but that's just an implementation detail. The "cvs add" at that point would have created the admin files in the "bar" directory and marked it as being a local instantiation of an existing directory -- thus other local working directory operations would know that the content of the directory was still unknown locally. (this would likely require some new admin file or flag somewhere, but that's also just an implementation detail) > What happens if a user invokes "cvs add" to create a file that already > exists in the repository but not in the workspace, given that the > client has conjured up its own metadata about the bar directory? > > Seems to me that it should just work, but I have to ask. :-) Well the "new" local file will be marked as added to the local directory so that a subsequent "cvs commit" will try to commit it as a new file. However since the file does already exist in the repot the result will be the simple standard ``Move "bar" out of the way, it already exists'' kind of error. A "cvs update" (or even "cvs update bar") would also generate the same error/warning of course, so the user can find out about the conflict at his or her leisure and without having to have been connected at "cvs add" time. -- 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 add' client/server semantics (was Re: Triggers)
[ On Sunday, January 30, 2005 at 22:24:06 (-0800), Mark D. Baushke wrote: ] > Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) > > - 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. Those two are logically the exact same "reason" (the first is just a specific form of the second), but neither are valid for CVS: The user has the option of doing an immediate "cvs commit" of an empty file if he or she wants to know if the filename is acceptable to the repository. The core CVS program must not force these kinds of timing decisions on the user. Besides t If a shop wants to enforce this kind of policy with some kind of technical control then they have the option of writing a wrapper program that has a "create file" feature which will create an empty file, "cvs add" it, and then immediately "cvs commit" it. A shop also has the option of writing their own CVS client that combines the "cvs add" and "cvs commit" operations into one so that a file must always be immediately commited (even if empty, just to reserve the name). A shop also has the option of writing wrappers, or alternate client programs, that use other repository server programs to check repo policies at "cvs-wrapper add" time. None of the above require any server contact to be done in the core CVS program within its basic "cvs add" function -- they can all be done externally in those few places where someone might think they are necessary. > 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. This kind of nonsense goes way beyond the basic change tracking functionality of CVS and tries to turn CVS into a project management tool. Such things are best done by additional tools since they have an extremely narrow application in a very limited number of shops. The *info scripting hooks in CVS are only intended to make site customization possible for things like reporting functions, and to provide hooks for for very basic consistency checks. CVS is supposed to keep out of your way, not get in your face at every point you interact with it. > Certainly he is not suggesting > any client/server protocol change and the addition of a trigger is very > simple to accomplish. Well actually he is requiring a protocol change -- at least if it's to be done right. And remember he'd likely also want "cvs rm" triggers. > No client changes are required, so only the server > needs to be upgraded to add the new functionality. Again, to do it right I think it would -- and then there's "cvs rm" > Greg's arguments for not contacting the server on a 'cvs add' would > require the semantics of a 'cvs commit' to be extended to allow for new > directories to be created Well it depends on what level you're looking at, but no, 'cvs commit' semantics are not really changed -- my complete "cvs add" revamp already covers this whole issue. Remember directories are not tracked in any way -- they're just placeholders for filenames. They simply come and go as required. If there are files to go in a directory then the directory has to exist, and if there are no files to go in it then it does not exist (though of course files are never really removed in the repository since their history must be preserved, but that's already handled by the prune option (which shouldn't be an option -- it should always happen). > So, from an implementation point of view, it would appear that Paul's > proposal is easier than Greg's. They're not even really related -- my "cvs add" proposal simply fixes the long standing problems and bugs to bring it in line with "cvs rm" from a UI perspective. Paul's proposal is only really about adding server hooks to all client commands. The only reason my proposal pushes Paul's "I have to have total centralized control" hot-button is because I take away one of his potential points of control -- one he should never have been able to consider as possible in the first place. He spends a lot of time and effort arguing for total centralized control over the client operations, but he lost
Re: 'cvs add' client/server semantics (was Re: Triggers)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Sander <[EMAIL PROTECTED]> writes:
> On Jan 30, 2005, at 10:24 PM, [EMAIL PROTECTED] wrote:
> > 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).
>
> I'm not sure I fully understand what was said in this paragraph, but
> I'd like to say that I believe that adding directories should also be
> triggerable events, and that policies enforcing directory additions
> could be potentially different from policies enforcing file additions.
> Expanding on Mark's example, a second policy might require that
> directory names can not contain period (".") characters. To make this
> happen, the trigger must be aware of the kind of artifact that's being
> added.
At present, a 'cvs add' will create a new directory and the 'loginfo'
trigger will be run with the new directory name given to the script. So,
the cvs administrator has no option to fail the 'cvs add' operation
before the new directory is already part of the repository.
That is to say, that 'cvs add' does have a trigger it uses, just that it
is not useful to a preemptive action.
> > - 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.
>
> This is true, and integrating triggers into import requires a lot of
> thought. I would suggest as a topic of discussion that import should
> scan the input tree and run all triggers in advance of the first
> change of persistent state. But this is a very touchy subject because
> the vendors that make the drops may in fact make changes to the tree
> that violate local policy. The CVS admin is then faced with a
> dilemma: Should the tree be imported as-is for accurate tracking of
> vendor drops, or should the tree be adjusted according to local policy
> and potentially breaking the vendor drop?
That would seem to want to be a knob in the CVSROOT/config file for
setting policy. However, at the least, I'd suggest that passing the
names of the tags to be used for the vendor and version to the 'taginfo'
trigger is probably desirable to try to stop folks from stomping on an
important tagname that might already exist in a previously imported
revision.
> > - 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
>
> I think this is common only when the user has read-only access to the
> repository, correct?
Yes. Or, when a user is using a 'guest' account for read-only mirror
rather than the read-write accout she may be entitled to use with the
primary repository that may be hidden behind a firewall of some kind.
> > 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.)
>
> Depends on what you mean by "resolve". After mv'ing a directory in a
> workspace to something new, CVS still maps it to its original location
> in the repository. If you're thinking about somehow having the rename
> be reflected in the repository, then you're treading dangerously close
> to another heated argument. :-)
If I move 'foo.c' to 'bar.c' the CVS/Entries file is going to be confused.
In general, doing lots of bulk renaming and local 'cvs add' and 'cvs rm'
operations without contacting the repository could be useful in some
situations, but could be very confusing as well.
I was trying to outline what I thought I read as reasons behind the
desire that 'cvs add' and 'cvs rm' operations should all be local.
It is possible that I have misrepresented them.
> > 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).
>
> Yes, this is an issue.
>
> > - 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
Re: 'cvs add' client/server semantics (was Re: Triggers)
On Jan 30, 2005, at 10:24 PM, [EMAIL PROTECTED] wrote:
-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...
[ Reasonable example involving MyFoo.h vs. myfoo.h naming in a mixed
Unix/Windows shop omitted ]
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.
I agree that it could be a potential source of confusion for the users.
They're confused about the whole concurrent development paradigm, too.
Both sources of confusion can be cleared up with the proper training.
Also, I'm recommending that add-time triggers be optional, not
advisory. "Optional" means that that they can be turned off.
"Advisory" means that they can be ignored. There are two differences
between the two concepts: Advisory triggers must always contact the
server to provide their advice, and they never block an operation.
Optional triggers contact the server only when they're turned on, and
they block additions when they're turned on and fail. I also strongly
recommend that, if the "cvs add" command is used in such a way that the
trigger fires and fails, the Entries file not be modified and the exit
code should indicate an error condition (not a warning).
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).
I'm not sure I fully understand what was said in this paragraph, but
I'd like to say that I believe that adding directories should also be
triggerable events, and that policies enforcing directory additions
could be potentially different from policies enforcing file additions.
Expanding on Mark's example, a second policy might require that
directory names can not contain period (".") characters. To make this
happen, the trigger must be aware of the kind of artifact that's being
added.
- 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.
This is true, and integrating triggers into import requires a lot of
thought. I would suggest as a topic of discussion that import should
scan the input tree and run all triggers in advance of the first change
of persistent state. But this is a very touchy subject because the
vendors that make the drops may in fact make changes to the tree that
violate local policy. The CVS admin is then faced with a dilemma:
Should the tree be imported as-is for accurate tracking of vendor
drops, or should the tree be adjusted according to local policy and
potentially breaking the vendor drop?
- 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
I think this is common only when the user has read-only access to the
repository, correct?
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.)
Depends on what you mean by "resolve". After mv'ing a directory in a
workspace to something new, CVS still maps it to its original location
in the repository. If you're thinking about somehow having the rename
be reflected in the repository, then you're treading dangerously close
to another heated argument. :-)
c) allows a user to continue to do useful work even when access to
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
