Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transitiontomorrow
Tim Peters wrote: One glitch, which may be all over the place: some of the text files got checked out with Windows line ends, but most did not. For example, 14 of the 19 *.txt files in ZConfig ended up with Windows line ends, but none of the 37 *.py files did. Ack, no, none of the checked-out .txt files did either. The .txt files that had Windows line ends were all created by svn for its own purposes (README.txt files in .svn directories). This is strange... from the SVN book ... Subversion examines the svn:mime-type property. If the file has no svn:mime-type property, or has a mime-type that is textual (e.g. text/*), Subversion assumes it is text. Otherwise, Subversion assumes the file is binary. Subversion also helps users by running a binary-detection algorithm in the svn import and svn add commands. These commands will make a good guess and then (possibly) set a binary svn:mime-type property on the file being added. ... What mime-types are associated with the files? --- Paolo Invernizzi ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transitiontomorrow
Paolo Invernizzi wrote: Tim Peters wrote: One glitch, which may be all over the place: some of the text files got checked out with Windows line ends, but most did not. For example, 14 of the 19 *.txt files in ZConfig ended up with Windows line ends, but none of the 37 *.py files did. Ack, no, none of the checked-out .txt files did either. The .txt files that had Windows line ends were all created by svn for its own purposes (README.txt files in .svn directories). This is strange... from the SVN book ... Subversion examines the svn:mime-type property. If the file has no svn:mime-type property, or has a mime-type that is textual (e.g. text/*), Subversion assumes it is text. Otherwise, Subversion assumes the file is binary. Subversion also helps users by running a binary-detection algorithm in the svn import and svn add commands. These commands will make a good guess and then (possibly) set a binary svn:mime-type property on the file being added. ... What mime-types are associated with the files? None. The files were not added or imported. They were input via cvs2svn, which uses dump files. The cvs2svn utility apparently doesn't set mime types, or any other property except cvs2svn:cvs-rev. So, given your explanation, why did Tim get bad line endings I wonder. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transitiontomorrow
Jim Fulton wrote: None. The files were not added or imported. They were input via cvs2svn, which uses dump files. The cvs2svn utility apparently doesn't set mime types, or any other property except cvs2svn:cvs-rev. So, given your explanation, why did Tim get bad line endings I wonder. Jim I've never used cvs2svn, but if It emit a dump file, I guess you imported the dump with svnadmin load, wich I think does not try to guess the mime type... --- Paolo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transitiontomorrow
Paolo Invernizzi wrote: Jim Fulton wrote: None. The files were not added or imported. They were input via cvs2svn, which uses dump files. The cvs2svn utility apparently doesn't set mime types, or any other property except cvs2svn:cvs-rev. So, given your explanation, why did Tim get bad line endings I wonder. Jim I've never used cvs2svn, but if It emit a dump file, I guess you imported the dump with svnadmin load, wich I think does not try to guess the mime type... I think that dump/load is lower level than that. I expect that the setting of properties should be done when the dump file is created. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Should we require windows users to use tools that honor Unix line endings? (Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transitiontomorrow)
Tim Peters wrote: [Jim Fulton] ... You will be able to do read-only anonymous checkouts like so: svn co svn://svn.zope.org/repos/main/project/trunk For example: svn co svn://svn.zope.org/repos/main/ZConfig/trunk FYI, I tried that on Windows (XP), and it worked fine. One glitch, which may be all over the place: some of the text files got checked out with Windows line ends, but most did not. For example, 14 of the 19 *.txt files in ZConfig ended up with Windows line ends, but none of the 37 *.py files did. Ack, no, none of the checked-out .txt files did either. The .txt files that had Windows line ends were all created by svn for its own purposes (README.txt files in .svn directories). I'm not sure what to do about this. Best I can tell from the docs so far, svn wants a svn:eol-style property added to every line-oriented file, with value native in order to get platform-sane line-end conversions. The doc's explanation of the effect of that matches my understanding of what CVS does for all non-binary files, which is usually exactly right. I noticed that Fredrik Lundh complained about something similar here: http://effbot.org/zone/subversion.htm ... Properties are nice, but having to use three different commands to check in a text file from Windows is pretty annoying. Looks like svn *expected* us to do this by setting enable-auto-props during the intial imports, with a bunch of [auto-props] settings in a config file; like [auto-props] *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.py = svn:eol-style=native *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.sh = svn:eol-style=native;svn:executable *.txt = svn:eol-style=native *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg I found this to be so unbelievable, that I had to resoearch it myself. After looking this up in the book and expressing my amazement on the #svn channel (and recieving confirmation from svn developers there), I have to admit that you are right. I know better than to doubt you, but this is just so unbelievable, I couldn't help it. I think we'll have to develop a standard set of config file settings like that for committers to add to their personal svn configs -- I don't think that this is practical. I think it will be very hard to communicate this to everyone. Plus, every time someone comes up with a new dang file suffix, everyone will have to update their config files. I think the real answer, the answer that the svn (and arch) developers believe in the heart of hearts is that windows users should be using tools that understand, well, understand and always produce Unix line endings. Is it practical to require windows users to use tools that understand and produce Unix line endings? or can that be done on the server side? I suppose it could. I think that a post-commit script could inspect new files and, for any new file that has no mine-type property, or has one with a text type, set the svn:eol-style proprty to native. It would have to do this in a separate transaction. Does anyone want to volunteer to write this script? We'll also need to fix cvs2svn to do something similar. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Should we require windows users to use tools that honor Unix line endings? (Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transitiontomorrow)
Jim Fulton wrote: I think the real answer, the answer that the svn (and arch) developers believe in the heart of hearts is that windows users should be using tools that understand, well, understand and always produce Unix line endings. Is it practical to require windows users to use tools that understand and produce Unix line endings? It is not a problem, but it would be odd. Python don't make me do it. Why then should the version control system do it? It's not difficult to find a Windows editor that understands unix line endings, but it would be very easy to forget to ocasionally convert dos files to unix. regards Max M ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversion transitiontomorrow
[Jim Fulton] ... You will be able to do read-only anonymous checkouts like so: svn co svn://svn.zope.org/repos/main/project/trunk For example: svn co svn://svn.zope.org/repos/main/ZConfig/trunk FYI, I tried that on Windows (XP), and it worked fine. One glitch, which may be all over the place: some of the text files got checked out with Windows line ends, but most did not. For example, 14 of the 19 *.txt files in ZConfig ended up with Windows line ends, but none of the 37 *.py files did. Ack, no, none of the checked-out .txt files did either. The .txt files that had Windows line ends were all created by svn for its own purposes (README.txt files in .svn directories). I'm not sure what to do about this. Best I can tell from the docs so far, svn wants a svn:eol-style property added to every line-oriented file, with value native in order to get platform-sane line-end conversions. The doc's explanation of the effect of that matches my understanding of what CVS does for all non-binary files, which is usually exactly right. I noticed that Fredrik Lundh complained about something similar here: http://effbot.org/zone/subversion.htm ... Properties are nice, but having to use three different commands to check in a text file from Windows is pretty annoying. Looks like svn *expected* us to do this by setting enable-auto-props during the intial imports, with a bunch of [auto-props] settings in a config file; like [auto-props] *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.py = svn:eol-style=native *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.sh = svn:eol-style=native;svn:executable *.txt = svn:eol-style=native *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg I think we'll have to develop a standard set of config file settings like that for committers to add to their personal svn configs -- or can that be done on the server side? To do a writable checkout (if you are a contributor who has submitted a version 1.1 contributor's agreement), you will use svn+ssh: svn co svn+ssh://svn.zope.org/repos/main/project/trunk Is that supposed work already? All I've been able to get out of it is, e.g., C:\Codesvn co svn+ssh://svn.zope.org/repos/main/ZConfig/trunk szc2 svn: Connection closed unexpectedly where the error msg appears very quickly (usually well under a second). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
