Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Gerhard, > I never had a problem with this decision. I only delete the > revisions that for one reason or another (well, it's always > space :) I have to delete. The others just stay there. The last time you did this - did you take a backup before running the admin command? > > But at a purely technical level - all "admin" commands are > dangerous > > (it's why they are called admin commands). Deleting -kB > revisions may > > or may not work > > I think this is the issue, for me at least. If there is a > known bug -- and a command that's supposed to do something > but doesn't do it (or even may not do it) is a bug IMO --, > that command should be disabled. So just don't let the > command delete revisions on files that are or at any point > were -kB. Similarly for all other known malfunctions. I am not aware of any bugs that need fixing in relation to this. There *may* be a bug, but in that case someone can fix it. The point I am replying to is a question about best practice - not a bug report. Regardless of whether the admin command works correctly first time every time or whether it fails every second time - it should only be used after a backup and only by an admin. > > I personally think any admin command in a GUI is a "bad thing" - it > > propagates the myth that this is a "user command". > > I like the support of a GUI for admin purposes for some > things. Why should an admin not use a (graphical, hence GUI) > revision graph for admin tasks? Yes - an admin gui is good - I phrased my point poorly which is why I used the example. > > > It's a bit like adding a GUI for fdisk into windows explorer. > PartitionMagic is not Windows Explorer - you need to start a specific application to do the admin task - which is (IMHO) as it should be. WinCVS is used by "users" and therefore is a tool I would prefer does not use "admin" commands. We added "chacl" functions to WM only after customers reported that "users" do indeed run "simple" chacl commands after the "admin" has set up the basic rights. But I'd never be OK with adding an "admin" command. > I don't think there's a good reason to leave :local: mode Well there are good reasons - just like there are good reasons for running admin commands - that's why the features are there. I'm just saying that "best practice" for a CM system is not to do put these things in the process. The problems with processes are that they are morally agnostic. Gerhard may have the moral wherewithal to know that deleting a revision of a binary file to save space is OK but deleting a revision of a C source file because it contained a bug caused by poor coding is NOT OK. But the process cannot be subjective in this way. And a "CM person" reviewing the tool capabilities/process will see that you are utiliising (or even encouraging) the subversion of good CM practices. I'm not suggesting (seriously) that either :local: or "cvs admin" be removed from CVSNT. I am wondering aloud if perhaps due to an oversight that these things are "too easy" to use without the necessary forethought. I suspect that "reversing" a change is actually more complex to understand than "deleting a revision" and that :local: is a lot easier to setup (in WinCVS) than a server and client on the same PC. If you are driving down the 6 lane freeway and it forks in two (one lane left, and 5 lanes right), there are large "green" signs painted above each that have the name of your destination on BOTH of them but the five lane sign says "emergency vehicles only" and the one lane sign says "all other vehicles". I would bet that most traffic will go the five lane choice, but unfortunately they do not know that after a mile the road ends at a precipitous drop. In a court of law the road maintainers could not successfully plead that they "told the motorists to drive the other route" because they failed in their duty of care to make the "right choice" clear/easy enough. I suspect the same rule should apply to software like CVSNT. Finally - I'm not actually intending on making any of these suggested changes in the near future. I mostly wanted to go on record at making it clear that the engineers consider the use of "admin" dangerous (even if the commands that work 100% of the time). The design of the code way back over the past 20 years has always assumed that people who run "admin" commands accept that this could require a restore from backup. And yes - storage is cheap - for Manchester we are purchasing a terabyte of SAN storage that will cost around US$2000. At 300Mb a week it'll take 64 years to fill. If you did a complete cost comparison of that cost verses the real cost of a single "fix and restore" (the os admin, cvs admin, tape retrieval, lost productivity all at billing rates) then you will probably find that the 1TB of storage is a lot cheaper. So in summary for the average commercial user purchasing a few terabytes of storage is cheaper than running admin commands every few weeks. On the subject of EVS - we are certainly thinking about how best to handle binary files. The first version will probably not contain anything specific, but the architecture will allow us to store different objects in different ways (eg: store binary files in the filesystem as bin-1 bin-2 bin-3 etc etc). Regards, Arthur Barrett