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 Tue, 23 Sep 2003 13:36:44 +0200, Michal Kara <lemming at is.cz> wrote: >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. >2) edit -b to not make backup copy on edit. This prevents using a lot of >space when user locks many files. unedit then doesn't restore the file, >but I consider that no issue. OK >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. > >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'. >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. > I have also patched WinCVS to be able to use these improvements and >to display which files has user locked (edited). We use patched CVS & >WinCVS for about two months in our development team and it seems to be >stable. But I need to put these changes into cvsnt first, before trying >to convice WinCVS people :-) > > So I want to ask a few questions: > >a) Where should I send the patch(es)? Add them as separate attachments to the bugzilla database (separate bug per item preferably). 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). 3 isn't going to happen... 4 & 5 sound like needless bloat but I'm open to persuasion. Tony