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.
Arthur Barrett wrote: >>> No - never ever ever use the admin command. >> >> I have (admittedly rare) applications for removing past (obsolete) >> revisions. It seems that I'm not the only one, as the "select non >> significant" revisions command in WinCvs seems to show: someone took >> the effort to implement it, and its main purpose seems to be to remove >> these revisions after selecting them. > > Ultimately it's a process issue - as I said originally - if you delete > one revision where do you stop? 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. And before you say "space is cheap", consider this: I want about a month history, plus selected revisions as identified by tags, the file accumulates around 300MB per week, which of course shows up in the several sets of daily, weekly and monthly backups. This quickly adds up to /a lot/. Of course, I could use something else and not cvsnt... but that's the tool I usually use. So I just use the admin command to get rid of the revisions I don't need and keep the space reasonable. (And WinCvs helps with this.) > 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 don't think that admin commands are supposed to be dangerously non-working. I routinely run database and system admin commands that are not available to normal users, and I expect them to work. Just because they work doesn't mean they should be available to normal users -- but just because they are not available to normal users doesn't mean it's ok for them to sometimes work and sometimes not. > my concern is that some people are treating the "admin" command like the > "update" command - the "admin" command should only be ran by an admin > and only after performing a full backup of the repository, whereas > "update" is ok for users to run. Of course, and that's why admin is restricted to repo admins. This is a good thing. > 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? > It's a bit like adding a GUI for fdisk into windows explorer. Well, ever since PartitionMagic have I enjoyed a GUI for partitioning. I like it. IMO it's safer and less error-prone than most command line tools, and definitely beats fdisk. > The "cvs admin" command already is restricted to admin users only - but > this is overridden (from memory) when in :local: mode (again :local: > mode is a "bad thing"), now "local mode", "cvs admin" and "wincvs" are > words that just go together too often and too easily... I don't think there's a good reason to leave :local: mode active. This is one thing I agree with you -- unless I miss something. But I can't see an application that would require :local: mode. The cited combination indeed sounds dangerous. But take :local: away, and that problem is solved... I think taking admin away is trying to fix the wrong end of the problem. At least I would have to start looking for another tool then. Gerhard