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.
>>1) CVS keeps the information whether the file is edited or not in >>Entries.Extra. I know it is not reliable (its just a hint), but it is >>very useful - user can see in GUI (e.g., WinCVS) which file he has >>locked. The other use is mentioned below (commit -e). > > > I'm not sure how useful that is.. It'd probably be wrong 95% of the > time and might lead people to expect it to be correct in some way > (leading to many bug reports I'd have to argue over) - 'cvs editors' > does the job and really is the only reliable method. > > Of course if you have the edit that information is already stored in > the sandbox, so you know that info anyway. 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. >>3) update -L - makes backup of the file, does update and puts the backup >>back. I.E., discards changes made in the repository copy. Dangerous (as >>well as -C), but has its use when someone mistakenly changes file in the >>repository, so you don't have to do this process by hand. > > > That's just *asking* to be abused. I don't see how someone can > 'mistakenly' change the repository, since the commit will fail if the > file is edited (provided everyone is forced to use commit -c eg. by > using a cvsrc file). If it has changed it's up to you to to a manual > merge on the data otherwise there will be loss of information. As for how, see explanation below. This switch actually does what you can do by hand, it is only more error-prone. >>4) commit -e - commits only files marked in Entries.Extra as edited. >>Useful when something touches files you didn't really change. In >>conjunction with -c prevents commit errors. > > More explanation needed here... If a file is modified it should be > committed. If it's a generated file it probably shouldn't be in CVS > in the first place. I'm not sure what you mean by 'touches files you > didn't really change'. 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.) >>5) commit -E - keeps file(s) edited after commit. Useful when you need >>to keep your files locked - you don't have to remember which files are >>"yours". > > Not sure about this - it encourages bad practice... The only reason > to do edit on a file is if you intend to edit and commit it. Once you > have committed it then you are stating that you have finished editing > it. This then gives the opportunity for other people who have been > waiting for you to finish (one of the reasons locks are so bad) to get > their chance. The last thing you want is to allow people to hold onto > locks indefinately. Two things to say here: CVS was developed with distributed development in mind - people scattered all around the world. There it may be important to give chance to other people. However, when the development team is close and is directed, it poses no problem. 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. > Add them as separate attachments to the bugzilla database (separate > bug per item preferably). I will, when we negotiate which ones you want :-) > I'd take item 2 and possibly 1 (with modifications - it should only > ever hold data about local edits as a hint for WinCVS... attempting to > find out about other editors this way is too misleading to be useful). I have explained 1 wrong, it is as you say. > 3 isn't going to happen... 4 & 5 sound like needless bloat but I'm > open to persuasion. 4 is, for the most, solution to a local problem, so I would agree to drop it, if you don't like it. The only argument I have is that you don't have to use it :-) 5 is useful for tight control over files. See above. 3 is also useful. I agree it may encourage bad practices, but it is nothing you couldn't do as well by hand, only less reliably. Michal Kara