[cvsnt] Re: cvsnt patches/improvements

Tony Hoyle tmh at nodomain.org
Wed Sep 24 13:30:00 BST 2003


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



More information about the cvsnt mailing list