[Python-Dev] *.dsp and *.dsw are treated by CVS as binary. Why? (original) (raw)
Trent Mick trentm@ActiveState.com
Sat, 12 Aug 2000 11:47:19 -0700
- Previous message: [Python-Dev] *.dsp and *.dsw are treated by CVS as binary. Why?
- Next message: [Python-Dev] *.dsp and *.dsw are treated by CVS as binary. Why?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Aug 11, 2000 at 08:59:22PM -0400, Tim Peters wrote:
Not really. They're not human-editable! Leave 'em alone. Keeping them in binary mode is a clue to people that they aren't supposed to go mucking with them via text processing tools.
I think that putting them in binary mode is a misleading clue that people should not muck with them. The are text files. Editable or not the are not binary. I shouldn't go mucking with 'configure' either, because it is a generated file, but we shouldn't call it binary.
Yes, I agree, people should not muck with .dsp files. I am not suggesting that we do. The "text-processing" I was referring to are my attempts to keep a local repository of Python in our local SCM tool (Perforce) in sync with Python-CVS. When I suck in Python-CVS on linux and them shove it in Perforce:
- the .dsp's land on my linux box with DOS terminators
- I check everything into Perforce
- I check Python out of Perforce on a Windows box and the .dsp's are all terminated with \r\n\n. This is because the .dsp were not marked as binary in Perforce because I logically didn't think that they should be marked as binary. Having them marked as binary is just misleading I think.
Anyway, as Guido said, this is not worth arguing over too much and it should have been fixed for you about an hour after I broke it (sorry).
If it is still broken for you then I will back out.
Trent
-- Trent Mick TrentM@ActiveState.com
- Previous message: [Python-Dev] *.dsp and *.dsw are treated by CVS as binary. Why?
- Next message: [Python-Dev] *.dsp and *.dsw are treated by CVS as binary. Why?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]