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.
On Wed, 24 Sep 2003 13:49:16 +0200, Michal Kara <lemming at is.cz> wrote: > Oh sorry, I have not explained it properly. Of course it tracks >whether file is edited in THIS sandbox (i.e., by user of this sandbox). > > 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. > 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. > And moreover, when you have binary files, you need to have tight >control over who makes changes, because it is usually impossible to >merge changes (other than re-doing one of them on the top of the other). >So to solve this, each user has a set of files he is working on (for >exapmle, a scene, or a mission). Other users change these files only >rarely. So it makes perfect sense for him to have these files always >locked for himself, so he has control over them. 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). 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). Tony