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.
This has been saked on the cvsgui list today, and I have made some tests which lead to the following questions concerning how to change the file type for an existing file: Consider the file Form.dfm, it is a Delphi form file and was originally added to CVS when Delphi handled these files in binary format. Thus it was added binary via WinCvs GUI. The revision history is like this: 1.1 (bin) 1.2 (bin) 1.3 (bin) 1.4 (bin) 1.5 (bin) Now the file can be handled by Delpi as text so we want to convert it to text format, this is easy enough. But the file thus committed will still retain its binary state in CVS. So we continue our revision history: 1.6 (bin, but really in text format) 1.7 (bin, but really in text format) 1.8 (bin, but really in text format) Now we hear about the possibility to switch to the normal text mode for this file so we want to do this (exact command needed). After the switch I assume the revision continuation will be like this: 1.9 (text) 1.10 (text) 1.11 (text) Now the crucial questions: 1) What is the exact correct command to give to make the switch 1.8->1.9 that makes the file text from then on? 2) What will happen if I update an existing sandbox to retrieve the file in revision 1.3? Will it be marked in my sandbox as a text or binary file? 3) What happens if I have a branch based on 1.4, which needs to be merged into Trunk when HEAD is in 1.11? 4) What will happen if the branch is based on rev 1.7 instead? My tests with CVS version 2.0.11 (client and server) are mixed blessings, it seems like the file will be marked as -kt as opposed to nothing for a normal text file. And the update to a binary revision does not change this at least not in my WinCvs version. It would be good to have this cleared up once and for all and then put it into the Wiki since I have a feeling that there are a lot of potential such files around (we sure do have them...). Bo Berglund