[cvsnt] Undo Commit?

[Arthur Barrett]

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