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.
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