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.
>> What users would like is to see in GUI who is editing which file, but >>that would be 95% time wrong, as you write. Making it online is almost >>impossible on current CVS architecture. So what I did is that I provided >>them information which files they edit. > > I'm OK with that. OK, I consider item 1) as acceptable. >> We have scene editor which stores data in several files (e.g., paths, >>sounds, textures). It saves all these files at once. So if you change a >>texture, timestamp of the sounds file is also changed. > >> (The other way round this would be to store also file checksum in >>Entries.extra and to check it to really determine, whether a file is >>changed (only when modification time is change, of course). I can >>develop this solution, if you would accept it.) > > CVS already does a difference and only really does a commit on the > changed files - there is the overhead of sending it to the server for > checking though. A checksum would be useful if it was robust enough > (MD5 or SHA1).. I'd prefer something like that if you've got the > time/inclination to write it. Of course checksumming isn't quick, so > the issue then becomes whether to put it on the server (and store it > in RCS) or do it locally during checkout. 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.) 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. > If one person is working solely on a project nobody else should have > any business committing new files, so it sounds like a project > management problem rather than a locking problem... I can see on a > large multi-site project though it can happen. If it were me I'd out > a watch on the file so I could email the culprit and ask what changes > they had made, etc. (but then I generally don't use locks even on > binary files - the when/where to use locks is another debate, though). I am not sure if you got me right - person is working solely on a subset of files of a project. 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. > When you update a nonmergable file it puts a copy of the repository > file in a separate file (eg. .#foo.bin, 1.1) and leaves your original > file alone, so it's already doing the best it can. IIRC it should be > possible to just commit the new file without any special treatment, > but it's a long time since I've had to deal with changing binary files > (we only usually store .gif and .bmp's in the repository, which don't > change much). No, it is the other way round. This is why I made -L flag. On conflict, cvs says (on update): U test.exe cvs server: nonmergable file needs merge cvs server: revision 1.2 from repository is now in test.exe cvs server: file from working directory is now in .#test.exe.1.1 C test.exe So you have to rename backup file back and then commit. And what about the -E flag (keep file edited/locked)? 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? Thanks, Michal Kara