I would personally be loathe to make any feature that doesn't require a connection require one if it could be helped. In fact, I've actually been thinking about disconnecting some of the other functi
It's fair to say that the client shouldn't gratuitously contact the server. On the other hand, I think it's safe to say that several of us in this forum disagree over what is gratuitous. I happen to
policies such a This might be true, but it seems to me that most damage due to your "lost productivity" could be fixed with a rename or two and maybe a few `sed' runs, in a few minutes. At least in a
It depends on the nature and extent of the changes. I can easily imagine scenarios in which lost productivity would be measured in days, even assuming that all files are ASCII. The thing is, if ther
policies things prefers to made fail I still disagree, because some people like working from their laptop and wireless network connections are hardly ubiquitous yet. Work that a developer can do from
I still disagree, because some people like working from their laptop and wireless network connections are hardly ubiquitous yet. Work that a developer can do from their laptop off of the network can
[ On Wednesday, November 17, 2004 at 09:19:18 (-0800), Paul Sander wrote: ] Your imagination is far too ripe with bizzare paranoia. There is no trigger for "cvs rm" and there MUST _NOT_ be. There is
Please defend your position for 'MUST NOT' as it seems an entirely reasonable suggestion that additional triggers might wish to be imposed by a repository administrator. Today, there is no direct tri
Which of course is an extremely stupid way to implement something that is done for the sole and lone reason of policy enfocement. ;-) It would be saner and safer and much Much MUCH simpler to just wr
I have to admit, there is a certain logic to drawing the line at triggers for repository changes, not workspace changes. The user should have total control over their workspace and the server shouldn
Price wrote: ] third-party sources and adding/committing changes) Only if you view the policy enforcement as policing. If you view it as a development tool, it makes perfect sense. I know that if Pau
I believe this is the crux of the argument, the user should be allowed to do anything they want to in their sandbox, but when they want to change the repository their changes have to conform to any o
Hi Greg, Is it reasonable to suggest that a addinfo trigger could be run as a part of the 'cvs commit' command should the client not happen to connect to the server for a 'cvs add' operation? The ide
Absolutely. I intended this as a suggestion for a potential additional patch which I would find acceptable if submitted. I in no way meant to imply that it be a condition for acceptance of any patch
It should probably run regardless since it would be much simpler than securely tracking whether the add on the client side had contacted the server. Sure, but again, not by default. That's a good poi
Good point. Sure. Given we do not currently have those hooks, I have no objections to considering a patch that does this. I recommend this be an option that could be requested by the user or the defa
Sure. Cheers, Derek - -- *8^) Email: address@hidden Get CVS support at <http://ximbiot.com>! --BEGIN PGP SIGNATURE-- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigm
It's backed by many years of experience. I wasn't going to mention this, but since you brought it up, removals should also be triggerable events and the same philophy, whatever it is, should be appl
It's simpler, but neither safer nor saner to wrapper script around the client. The reason is this: If you enforce policy but give the user an avenue to circumvent it, the user will do so. If you're
Actually, your arguments in favor of deferment vs non-deferment are not as compelling as the idea that 'cvs add' and 'cvs rm' should be local to the tree until such time as a real 'cvs commit' event