Re: "cvs move" command

[Kaz Kylheku]

Andrew Volkov <Andrew.Volkov@transas.com> wrote in message 
news:<mailman.720.1043175303.21513.bug-cvs@gnu.org>...
> IHMO, it would be VERY BETTER to store in dbase (MySQL as first candidate, I
> think), in this 
> case you may not trouble about hash, will get right rolling back (in case,
> if dbase support transactions), simplify administration, GUI clients,
> backup/restore ...

You don't need a database to get atomic transactions. Firstly, CVS is
already atomic, but at the granularity of individual files. When you
commit or tag a whole bunch of files, each individual file is either
committed or tagged, or it is not. That is atomicity. The set as a
whole is not treated atomically, however. But it's a white lie to say
that there is no atomicity at all.

Believe it or not, this finer-grained atomicity doesn't cause any real
problems in practice. If you follow the CVS help mailing list, this
rarely comes up as a real issue that someone is having. The only
people that whine about atomicity are those who advocate other version
control systems. So of course, it's in their interest to inflate every
little blemish in CVS to make it seem like a catastrophic misfeature.
This is called FUD!

Destructive operations on CVS version files could be made atomic in a
trivial way: the temporary files could be prepared in one pass, and
they could be renamed in another pass. Some information scribbled in a
journal file at each checkpoint would allow for recovery; after a
crash and reboot, the renames could be completed if all the temporary
files are present, or else the temporaries could be removed as if
nothing happened. Locks get cleaned up and life goes on.

The only problem with this approach is that it has some pretty bad
worst-case disk usage to keep the temporary files. Otherwise, it's
feasible in every way. We could have an atomic CVS done in this manner
next month, if someone really cared about this problem.

Interrupted CVS commits don't cause any real damage. You repeat the
commit operation and it will put in what was missed. In effect the
client sandbox acts as a journal which knows what was committed and
what was not. The only ill effect is that there is a time difference
in the timestamps; tools which reconstruct patch information from the
output of CVS log will not realize that a commit was split into two.
There is also the risk that someone will pick up half your commit and
get a broken build of the software. So what? This can happen even with
atomic commits, when people selectively commit some files, but forget
others. Or they add dependencies on some new files, but forget to add
those files to version control. This is a temporary condition that is
resolved by developer communication.

A database will simplify administration? In what dreamworld?

GUI client? Yeah right, a generic database window showing a list view
of rows and rows of records in some cryptic tables is *not* a version
control GUI! An effective GUI for version control has to be designed
from the ground up. Since it's on the client side, it will likely not
see the RDBMS directly, but rather speak the version control system's
protocol.

Backup/restore? With CVS you have dump, tar, cpio ...

Filesystems are far simpler to back up and restore than databases. 

The structure of the CVS storage can be subject to easy *selective*
restoring, and manual repairs.

> For me it's 
> along reason, why converting cvs to dbase is problematically.
> 
> Comments?

Another reason is problematic is that it's a big software project!
Show me the code.
 
> P.S. Please reply me directly, I'm not in mail list.

Doh, go to groups.google.com, and select gnu.cvs.bug.