[cvsnt] Re: cvsnt patches/improvements

Thu Sep 25 18:05:49 BST 2003

There is another patch I would like to see in CVSNT. I don't know if Tony is already working on somethink like this, but sending diffs to the servers instead of complete files would be a big performance enhancement since network latence is usually worse then local file system latence.
It would work like something like this:

in the client side:
if CVS\Base dir has a copy of the file, send a diff to the server
else send complete file

in the server side:
if a diff is sent, recreate the file in temp dir patching it from the version the client file is based on
else put the complete file in temp dir

I think the new file transmition could be allowed if just after authentication the client send a new command requesting diff transmitions. If an error is returned the client assumes it's communicating with a regular CVS server. If an OK is returned, the client assumes diff file transmition is allowed. The changes needed in the protocol won't break compatibility this way and the file tramsmition could be done by sending diff size and a "diff" string, newline, and diff contents. The regular file transmition may remain "file size, new line, contents".

BTW, how is the implementation of database storage on mysql? Are you planning to use any binary diff algorithm for binary files?

Cheers,

Zandall.

> -----Original Message-----
> From: Tony Hoyle [mailto:tmh at nodomain.org]
> Sent: Thursday, September 25, 2003 6:05 AM
> To: cvsnt at cvsnt.org
> Subject: [cvsnt] Re: cvsnt patches/improvements
> 
> 
> Michal Kara wrote:
> 
> 
> >    But if I remember it correctly: When the local file is 
> touched (has
> > only mtime changed) and file on the server has changed, CVS 
> generates
> > conflict, but there really isn't any. (When the file has 
> not changed on
> > the server, it goes OK, as you say.)
> 
> It's always worked for me... it's not an uncommon occurrence 
> to accidentally
> save a file you haven't changed.
> 
> >    I would store file length and checksum in the Entries.extra. The
> > commit algorithm would be:
> > 
> > 1) When file commit is forced, commit file
> > 2) When file mtime matches, do nothing.
> > 3) When file length does not match (or is not present), commit file
> > 4) When file checksum is not present, commit file
> > 5) When file checksum matches, set file's mtime to the 
> stored one and do
> > not commit
> > 
> >    I would prefer MD5, it is really good checksum. If you 
> agree to this
> > solution, I will try to write patch implementing this.
> 
> There's already a checksum algorythm (it's used by the patch 
> code to verify
> that the patch went OK) you should be able to hook into that somehow.
> 
> Be careful about the commit algorythm - it's more complex 
> than that - you
> really want to just add a check somewhere in Classify_File 
> which does an
> extra layer of validation if the time is different.   Trying to make
> complex logic is going to break in quite a few circumstances.
>  
> >    The problems we expirience come from the fact that our 
> scene editor
> > touches files that are not really changed. This is our 
> local thing. The
> > second problem is that people who use the system are 
> non-techies - they
> > are game designers and (graphic) artists. So it is 
> difficult for them do
> > decipher CVS error messages that they are trying to commit 
> file they do
> > not have locked and to retrieve a clean copy from 
> repository. This is
> > why I made -e flag.
> 
> I don't see how this can happen - if the person is working 
> solely on the
> repository then maybe the modification time might change, but 
> since nobody
> else will have committed a version into the repository it 
> won't be an issue
> (and the server will see there's no difference and not create a new
> version).  If your scene editor is really making changes to 
> the files then
> they probably shouldn't be in CVS since they'll be regenerated locally
> anyway.
> 
> >    BTW, we expirience another problem, I have not yet  
> found solution
> > to. We use Windows clients and Linux server. When someone 
> renames file
> > to same letters, but different case, CVS starts producing 
> strange errors
> > (i.e., I have Picture.gif, rename it to Picture.GIF, remove 
> Picture.gif
> > from CVS control and add Picture.GIF). This is clearly 
> because Windows
> > are not file name case sensitive, but Linux is. It does not 
> happen too
> > often, but - have you ever tried to solve this?
> 
> It's not solvable - if you're using Windows clients/servers 
> you mustn't play
> around with case.  Picture.GIF and Picture.gif are entirely 
> different files
> in Linux (in fact it's possible to have both in the sandbox 
> at once)...
> however it's impossible to store that fact in the repository 
> because the
> Windows server treats them as the same, which is a limitation 
> of the OS.
> 
> Tony
> 
> _______________________________________________
> cvsnt mailing list
> cvsnt at cvsnt.org
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
> 