AW: "cvs move" command

[Schoenebeck Christian]

>-----Ursprüngliche Nachricht-----
>Von: Kaz Kylheku [mailto:kaz@ashi.footprints.net] 
>Gesendet: Mittwoch, 22. Januar 2003 02:23
>An: bug-cvs@gnu.org
>Betreff: Re: "cvs move" command
>
>
>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 ...
>
>> 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.

A big part of CVS as it is now has to be redesigned one day anyway, perhaps
not in the near future but it has to one day. And why not designing it in a
way that people can extend it for using a DB instead. If they want to write
the code...

But I also agree that it does not really make sense to use a DB for a
versioning system. But again, if one day someone starts to write code for
using a DB, giving the user the chance to compile CVS either for the
conventional or for the DB way, would that be bad?