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.
> You can't merge any $...$ keywords in Linux CVS except $Log$, and only > then because of the way it works (because it preserves its existing > contents by default). Since $Log$ isn't that useful and merging the > other keywords is potentially much more useful, breaking that one case > is OK - it's personally saved me many hours of mucking around being > able to merge $Id$ for example. > > Tony So 'merging' $Id$ is a CVSNT feature? Just a few days ago I noticed a different behaviour wrt. $Id$ compared to what I was used to. I was used to get $Id$ updated, giving a conflict when merging the difference between two versions into a third one. Ignoring $Id$ when merging might save work if there is a conflict, but otherwise it doesn't seem to be the right thing to me. Imagine a build directory with a small local change that must not be checked in. When I update that sandbox from the repository, the $Id$ keyword doesn't get updated at all on locally changed files - even if there is no conflict to be expected. IMHO, if no conflict is to be expected, i.e. if the BASE revision of the local file is the same as the base revision of the patch, the $Id$ keyword should get updated, the same way it would if I did the merge by getting a diff between BASE and HEAD and applying it to the local files. I'm aware that this problem disappears as soon as I check in the locally changed file as the checkout following immediately updates the keywords. But there are valid cases where I don't want to do so. BTW, thank you Tony for all the work you are putting into CVSNT. Pascal