I wonder if anyone can help, I have successfully managed to import some word, excel and pdf documents into the CVS. When i check them out all of them have formatting problems and appear to just be ascii.
Hi Angus, I was chasing down a commit bug that had slipped off my plate so I didn't get a chance to look into this tonight. I do have some thoughts, it could be that the file was checked in as ASCII (i.e. the -kb switch was not set during the initial check in).
I will try to get around to this tomorrow, it will most likely mean doing some inspection of the file for binary bits and then guessing adding the option if they are found. If you want to take a stab at it yourself this would probably go in the Entry class.
Hi again Angus, I have added the KFlag property to the CommitCommand which is part of the solution. The second part will be to actually inspect the file and try to do some guessing on what type of file it is. I am not really sure if this belongs in the library component or not...this seems like it should require some user interaction so it might be more appropriate in the console application.
There is an option if you want to set this extension property across your whole repository you can checkout the CVSROOT module and modify the cvswrappers file:
This will allow you to apply the same rcs-kflag switch to all extensions (and should also fix your issue).
Have you also added the KFlag propery to the ImportModuleCommand, as this is what i am using to place the files into the CVS initially?
Hi Angus, I haven't been able to find anything on the k-flags option for a module import command. There is something to specify keyword expansion but it looks slightly different than specifying a binary file. The other strange thing is that the k-flag seems to act on the entire list of files bein added in the case of the add command. From what I can tell tortoise gets around this by performing a seperate add for each file (just determing this from poking around so far)...so I am going to do some looking into the import -W switch and see if that takes me anywhere.
Did you try using the Wrappers file before an import? Did that get you by the issue?
Sorry for not getting back to you sooner, going to have a look at the Wrappers file today before the import, will let you know if that solves the problem
I having been trying to edited the cvswrappers file to solve this problem, with little luck.
I have been adding the following to the file:
*.DOC -k 'b' -m 'COPY'
*.doc -k 'b' -m 'COPY'
*.PDF -k 'b' -m 'COPY'
*.pdf -k 'b' -m 'COPY'
*.XLS -k 'b' -m 'COPY'
*.xls -k 'b' -m 'COPY'
This as far as i know should handle the -kb switch, specifing that it is infact a binary file, i am unfortuntely still getting back garbage back when i checkout the files i have imported into the cvs.
not sure exactly how the unwrap and wrap options work which i found on the site you pointed me too:
*.nib -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'
this i think needs paths etc which cannot be passed from the library, i did discover that the version of cvs i was running did not support this, so i am going to upgrade, was using cvs version 1.11.2.
Which version are you using, and which do you recommend?
Hi Angus, I think the issue is that the existing file takes presendence. By this I mean if the file is initially checked in as text/ ascii then the k-opts associated with that file are 'sticky' even if the wrappers file is used. You can get around this by using the cvs admin command and resetting the k-opts there (I believe the syntax is cvs admin -kb [files]). After which you will have to an update that will reset all sticky tags (cvs update -A). What this basically does locally is change the CVS/Entries file by adding a -kb in the line item (for binar). The admin command is not implemented currently in sharpcvslib.
For the second part of this I usually use cvsnt and am currently testing primarily against 2.0.51d primarily. I also run against sourceforge and I believe they are running version 1.11.17 (at least in my shell session they are, this could be wrong). Most of the testing I do against this repository though is just checkout/ update and some commits. I also have a testbed on Linux, the version there is also 1.11.17. This points out an obvious gap in my testing of binary files and the import command but hopefully it clears things up.
So, I having said that I would recommend cvsnt. I have never set it up on a linux server however according to the documentation it should be possibe. The reason I would recommend cvsnt is that it is being actively worked on and new features are being rolled into the product whereas the traditional cvs product has not seen a lot of new improvements lately.
Hope that answers your questions...