ATTENTION! cvs to subversion transition tomorrow
Tomorrow, as planned. I'm going to move the main development branches for Zope 2, Zope 3, and ZODB to subversion. I will start the move at 10am US/Eastern time tomorrow. I plan to be done before 5pm US/Eastern time. During this time, I ask that no one make checkins to the CVS head for those projects. The first thing I will do is to tag the head with the tag: 'cvs-to-svn-conversion'. When I'm done, I will remove all files from the heads of the preojects in CVS, except README.txt files giving subversion access instructions. Speaking of subversion instructions, I'll be sending some later today. If you want to do writable subversion checkouts, you'll need to submit a version 1.1 contributor's agreement (if you haven't already). The contributor's agreement can be found at: http://dev.zope.org/DevHome/CVS/Contributor.pdf You can print and then send the filled out and signed agreement to us in one of 3 ways: - Ordinary mail to: Zope Corporation, 513 Prince Edward Street Fredericksburg, VA, USA, 22401 - Fax to 1.703.995.0412 - Email a scanned form to: jim@zope.com Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Tomorrow, as planned. I'm going to move the main development branches for Zope 2, Zope 3, and ZODB to subversion. I will start the move at 10am US/Eastern time tomorrow. I plan to be done before 5pm US/Eastern time. During this time, I ask that no one make checkins to the CVS head for those projects. The first thing I will do is to tag the head with the tag: 'cvs-to-svn-conversion'. When I'm done, I will remove all files from the heads of the preojects in CVS, except README.txt files giving subversion access instructions.
Grrrrr. The conversion is going to take longer than I planned. I'm going to start at 6am US/Eastern. I still hope to be done by 5pm.
Speaking of subversion instructions, I'll be sending some later today.
At this point, we have one "main" repository. Initially, this repository will include the Zope (Zope 2), Zope3, ZODB, ZConfig, zLOG, and zdaemon projects. I've set up a partial converion of these projects on svn.zope.org for you to play with tonight. You will be able to browse the repository at: http://svn.zope.org 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 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 Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
[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:\Code>svn 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).
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
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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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
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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
[Jim] ...
So, given your explanation, why did Tim get bad line endings I wonder.
The relevant info is scattered all over the docs. Bottom line is that svn does line-end conversions if and only if the svn:eol-style property on a file is set to a valid value (where "native" is what's wanted most often for text files). The text versus binary distinction also exists, but is irrelevant to whether svn converts line ends; the t-vs-b distinction only controls "whether a contextual merge is possible" ("Binary Files and Translation" section of the CVS Appendix).
All, We will *not* to the cvs to subversion transition today. Feel free to check in against the cvs head. Tim, Thanks for trying this out. It looks like we're not ready to convert yet. :( We need to sort out the issues you raised. Clearly, the move to subversion is going to take longer than I'd hoped. Let's try to sort these issues out today. If we can, maybe we'll try again tomorrow. If not, the transition may need to wait a few weeks. Jim 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 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:\Code>svn 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).
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
From: "Jim Fulton" <jim@zope.com>
I found this to be so unbelievable, that I had to resoearch it myself. [...] 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 --
Eh. WHAT!?! OK, that there are settings like these, but aren't they configured on the server? They are CLIENT side? That is very weird.
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.
Well, but that is also a setting that needs to be handled. I use TextPad which conserves line endings. But when I create a new file, it would typically save it with windows endings, unless I say so..
Is it practical to require windows users to use tools that understand and produce Unix line endings?
Maybe more practical than forcing them to have specific SVN settings, but only slightly so...
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.
I think this is the only possible solution...
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 --
[Lennart Regebro]
Eh. WHAT!?! OK, that there are settings like these, but aren't they configured on the server? They are CLIENT side? That is very weird.
I first used svn last night -- I'm no expert. AFAICT from staring at the docs, these are client-side settings. Someone who has administered svn for a real project should pipe in. For line translations, it appears that svn (and CVS) do that purely on the client side, and that makes sense: only the client knows which machine it's running on, so only the client knows whether line ends need to be converted (in both directions). The big pragmatic difference is that CVS clients always do line end translation by default; you have to do the -kb business explicitly to make a CVS client not do line end translations. svn defaults to treating files as raw byte streams, and it appears an svn client will do translation iff a file bears a "svn:eol-style native" property. By the time a new file gets to the server, it's in some (overly?) strict sense too late to decide to fiddle its line ends (although I bet that would work fine in practice -- but I don't see anything to suggest that svn supports it directly).
For line translations, it appears that svn (and CVS) do that purely on the client side, and that makes sense:
Yes, but I'm pretty sure there are default settings for which files that should be treated as binary on the server side in CVS. At least I rember setting it up. :´)
On Wednesday 28 April 2004 04:01 pm, Lennart Regebro wrote:
Yes, but I'm pretty sure there are default settings for which files that should be treated as binary on the server side in CVS. At least I rember setting it up. :´)
Yes, this is specified in the CVSROOT/cvswrappers file. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
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
(Sorry for the cross posting, but I think that all of the lists have an important stake in this issue.) In the text below, I respond to a report from Tim on the fact that, unlike CVS, subversion doesn't do any end-of-line translation for text files. If someone creates a file on a Unix-like system, it will have Unix line endings. If someone creates a file on Windows, it will have windows line endings. Depending on tools used, we could end up with files having mixed line endings. This has happened to us in the past when people using SMB used windows editors to edit files checked out and checked in using Linux CVS clients (using SMB). When this has happened, people found it really annoying. Subversion has a property that can be set on a file to cause end-of-line translation to take place. I have argued that the setting of this property should be automated and that the standard ways to do so with subversion are inadequate. I started a thread on the subversion users mailing list explaining my position and describing a work around that Tim suggested to me: http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=1... One of the subversion developers responded suggesting: - File adds are rare - Ad hoc mechanisms for setting the subversion eol-style property have worked for the subversion project itself. (Text files that I have looked at in the subversion repository do, indeed, have this property set.) It could be argued that we should try subversion's ad hoc approach to prove that, in fact, it doesn't work for us. For myself, I'm inclined to do what Tim suggested, and tell subversion to automatically set the eol-style for all files to native. This will fail loudly when binary files are checked in and I think that I can deal with that inconvenience. Note that this is a big improvement over CVS as generally, binary files will automatically *not* be treated as text files. (The danger being that the binary detection algorithm will occasionally fail.) Thoughts? If we think that it's worth *trying* the subversion developers ad hoc approach, then I think we could move forward with the transition sooner, perhaps the week after next. (I still need to arrange for setting the property during conversion, but I think I can manage that.) Jim Jim Fulton wrote:
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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote: ...
http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=1...
Ken pointed out that the links on this page don't work. :( Sigh Here are links that do work: http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=10439 http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=10444 http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=10445 http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=10449 Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Fri, 2004-04-30 at 11:33, Jim Fulton wrote:
Jim Fulton wrote: ...
http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=1...
Ken pointed out that the links on this page don't work. :( Sigh
Neither do many of the "next in thread" and "previous in thread" links. pipermail-doesn't-look-so-bad-now-ly y'rs, -Barry
On Friday 30 April 2004 12:25 pm, Lennart Regebro wrote:
Only that the Subversion people are wrong. Ad-hoc is not good enough. It must be able to be configurable on the server.
Another possible approach would be to write a script to use for adds instead of the default client; it could set all the right attributes as part of the add operation (do the "svn add" and then set the properties). The script could have our initiali policy hardcoded, and could import the policy configuration from the server (caching it and all that of course). This would mean adds have to be done with the custom client though, which could be a real problem for people who'd rather use TortoiseSVN. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Lennart Regebro wrote:
Jim Fulton wrote:
Thoughts?
Only that the Subversion people are wrong. Ad-hoc is not good enough. It must be able to be configurable on the server.
You may be right. This was certainly my initial reaction. I think, though, that we should at least try handling this the normal way and see how it works. If it doesn't work, we can try some server-side hacks. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
[Jim]
svn co svn+ssh://svn.zope.org/repos/main/<project>/trunk
[Tim]
Is that supposed [to] work already? All I've been able to get out of it is, e.g.,
C:\Code>svn 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).
Jeez Louise -- I peed away the whole night on this. Read about 70 messages on various lists with various people on Windows having the symptom. Most threads eventually fizzled out without a cure being found. The others had a variety of causes, none of which applied to me. Finally hit paydirt at the very end of: http://www.contactor.se/~dast/svnusers/archive-2004-02/1053.shtml which is a guide to setting up an svn *server* on Windows. The ultimate problem was that my user name on zope.org is tim_one, but that's not what svn on Windows thinks my user name is. In fact, I still have no idea what svn makes up for that, but it ain't tim_one. Things that don't work: + The svn --username switch: svn co --username tim_one svn+ssh://svn.zope.org/repos/main/ZConfig/trunk svn: Connection closed unexpectedly The link above warned that this wouldn't work, which opened the floodgates. + Embedding my user name in the URL: svn co svn+ssh://tim_one@svn.zope.org/repos/main/ZConfig/trunk svn: Connection closed unexpectedly + Setting the USERNAME envar (which WinXP sets automatically, and here I'm overriding it): set USERNAME=tim_one svn co svn+ssh://svn.zope.org/repos/main/ZConfig/trunk svn: Connection closed unexpectedly + Setting the Unixish LOGNAME envar, in poke-and-hope desperation: set LOGNAME=tim_one svn co svn+ssh://svn.zope.org/repos/main/ZConfig/trunk svn: Connection closed unexpectedly + Adding host svn.zope.org user tim_one to an .ssh\config file. I think that *should* have worked, but it's probably a limitation of the specific for-Windows ssh.exe I'm using here (but which has worked fine with CVS for years, and without a config file). Finally (give up <wink>?), what does work: + Setting the SVN_SSH envar appropriately: set SVN_SSH=ssh -l tim_one svn co svn+ssh://svn.zope.org/repos/main/ZConfig/trunk A trunk\info.py A trunk\datatypes.py ... Aarghghgh. Here's another that works, and this is the best: + Adding Host svn.zope.org User tim_one to an .ssh\config file. I tried that after reading a man page for SSH_CONFIG. It claimed that the keywords were case-insensitive, so I figured whoever wrote the Windows implementation must have screwed that up -- and, apparently, they did! all-obvious-to-the-most-casual-observer-ly y'rs - tim
Tim Peters wrote: <snip much pain and suffering> This, btw, is why I prefer the: svn co https:// ...protocol. Will this be supported? cheers, Chris - who suddenly wonder how the hell you get https to use key-based auth :-S -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Tim Peters wrote: <snip much pain and suffering>
This, btw, is why I prefer the: svn co https://
...protocol.
Will this be supported?
No. We discussed this already: the WebDAV stuff is slow, and has much weaker authentication semantics; it would also require us to go into the business of issuing SSL certificates. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Sorry for the false start. I totally missed a flaw in subversion's handling of text-file line endings. I suspect that this is fixable, but it's not going to be fixed today. I can't afford to spend much more time on this before Zope X3.0 gets to beta, so I don't expect to get back to this for a month or so. If you want to help, let me know. The next time we try this, I'll build a longer testing period into the plan, and, probably a more gradual migration (e.g. only move the ZODB head first.) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
I've done a conversion of a snapshot of the CVS database from yesterday. This is just to allow people to play with subversion and see what the respoitory might look like when we do cut over. To browse the respository: http://svn.zope.org/ To do a read-only checkout: svn co svn://svn.zope.org/repos/main/<project>/trunk or, to do a writable checkout: svn co svn+ssh://svn.zope.org/repos/main/<project>/trunk Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
I've done a conversion of a snapshot of the CVS database from yesterday. This is just to allow people to play with subversion and see what the respoitory might look like when we do cut over.
To browse the respository:
It seems to have some kind of dns problem? regards Max M
Max M wrote:
Jim Fulton wrote:
I've done a conversion of a snapshot of the CVS database from yesterday. This is just to allow people to play with subversion and see what the respoitory might look like when we do cut over.
To browse the respository:
It seems to have some kind of dns problem?
Hm, I can get to it from a machine outside of ZC or Zope.org. Is anyone else haveing troubles getting to it? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Me too! :( Strangely, it worked fine earlier today... Stefan On Mittwoch, Apr 28, 2004, at 21:01 Europe/Vienna, Jim Fulton wrote:
Hm, I can get to it from a machine outside of ZC or Zope.org.
Is anyone else haveing troubles getting to it?
Jim
-- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/
I was just able to browse it via ViewCVS... On Wed, 2004-04-28 at 15:01, Jim Fulton wrote:
Max M wrote:
Jim Fulton wrote:
I've done a conversion of a snapshot of the CVS database from yesterday. This is just to allow people to play with subversion and see what the respoitory might look like when we do cut over.
To browse the respository:
It seems to have some kind of dns problem?
Hm, I can get to it from a machine outside of ZC or Zope.org.
Is anyone else haveing troubles getting to it?
Jim
Oops, but now I can't! On Wed, 2004-04-28 at 15:01, Jim Fulton wrote:
Max M wrote:
Jim Fulton wrote:
I've done a conversion of a snapshot of the CVS database from yesterday. This is just to allow people to play with subversion and see what the respoitory might look like when we do cut over.
To browse the respository:
It seems to have some kind of dns problem?
Hm, I can get to it from a machine outside of ZC or Zope.org.
Is anyone else haveing troubles getting to it?
Jim
Jim Fulton wrote:
Hm, I can get to it from a machine outside of ZC or Zope.org.
Is anyone else haveing troubles getting to it?
Now it's back up. C:\>ping svn.zope.org Pinger cvs.zope.org [12.155.117.30] med 32 byte data: Svar fra 12.155.117.30: byte=32 tid=100ms TTL=53 Svar fra 12.155.117.30: byte=32 tid=100ms TTL=53 Svar fra 12.155.117.30: byte=32 tid=100ms TTL=53 Svar fra 12.155.117.30: byte=32 tid=110ms TTL=53 Ping-statistikker for 12.155.117.30: Pakker: Sendt = 4, modtaget = 4, tabt = 0 (0% tab), Gennemsnitlig tid for rundtur i millisekunder: Mindst = 100ms, størst = 110ms, gennemsnitlig = 102ms regards Max M
Jim Fulton wrote:
Sorry for the false start.
I totally missed a flaw in subversion's handling of text-file line endings. I suspect that this is fixable, but it's not going to be fixed today.
I think that this issue has been "resolved". I have updated my cvs to svn conversion software to set the svn:eol-style property to "native" on text files so that they will get Windows line endings when checked out on Windows and Unix line endings when checked out on Unix-based systems. I've updated the demonstration repository with the results of this conversion. Note that it's possible that existing checkouts will need to be discarded, as I've totallly rebuilt the repository. To browse the respository: http://svn.zope.org/ To do a read-only checkout: svn co svn://svn.zope.org/repos/main/<project>/trunk or, to do a writable checkout: svn co svn+ssh://svn.zope.org/repos/main/<project>/trunk Developers who add new files will need to set the svn:eol-style property on new text files. There are ways to automate this and we'll provide some guidence on this at: http://dev.zope.org/Subversion BTW, someone has done some work on that Wiki, which was a copy of dev.zope.orf/CVS, to convert the CVS references and instructions to refer to and document Subversion instead. Thanks! I think that there is still a good bit of work to do. Volunteer help would be much appreciated. I'm thinking of trying again to do the cvs to svn conversion of the main-line development branches (cvs heads) on Tusday May 11. This would entail moving ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig, zdaemon, and zLOG). Any objections? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Wednesday 05 May 2004 01:59 am, Jim Fulton wrote:
I'm thinking of trying again to do the cvs to svn conversion of the main-line development branches (cvs heads) on Tusday May 11. This would entail moving ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig, zdaemon, and zLOG).
+1 -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Wed, 2004-05-05 at 02:59, Jim Fulton wrote:
Jim Fulton wrote: [...] I'm thinking of trying again to do the cvs to svn conversion of the main-line development branches (cvs heads) on Tusday May 11. This would entail moving ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig, zdaemon, and zLOG).
Any objections?
Isn't that the day of the next ZC IRC session? How will that be affected by the migration? Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
I plan to do the transition tomorrow, Tuesday may 11. I'll begin at 10am US/Eastern and be done by 5pm US/Eastern. During this time, I ask that no one make checkins to the CVS head for those projects. The first thing I will do is to tag the head with the tag: 'cvs-to-svn-conversion'. When I'm done, I will remove all files from the heads of the preojects in CVS, except README.txt files giving subversion access instructions. Jim Jim Fulton wrote:
Jim Fulton wrote:
Sorry for the false start.
I totally missed a flaw in subversion's handling of text-file line endings. I suspect that this is fixable, but it's not going to be fixed today.
I think that this issue has been "resolved". I have updated my cvs to svn conversion software to set the svn:eol-style property to "native" on text files so that they will get Windows line endings when checked out on Windows and Unix line endings when checked out on Unix-based systems. I've updated the demonstration repository with the results of this conversion. Note that it's possible that existing checkouts will need to be discarded, as I've totallly rebuilt the repository.
To browse the respository:
To do a read-only checkout:
svn co svn://svn.zope.org/repos/main/<project>/trunk
or, to do a writable checkout:
svn co svn+ssh://svn.zope.org/repos/main/<project>/trunk
Developers who add new files will need to set the svn:eol-style property on new text files. There are ways to automate this and we'll provide some guidence on this at:
http://dev.zope.org/Subversion
BTW, someone has done some work on that Wiki, which was a copy of dev.zope.orf/CVS, to convert the CVS references and instructions to refer to and document Subversion instead. Thanks! I think that there is still a good bit of work to do. Volunteer help would be much appreciated.
I'm thinking of trying again to do the cvs to svn conversion of the main-line development branches (cvs heads) on Tusday May 11. This would entail moving ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig, zdaemon, and zLOG).
Any objections?
Jim
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
I'm about to begin the conversion now. Please don't make any more changes to the Zope, Zope3, ZODB, ZConfig, zLOG, or zdaemon CVS heads. Jim Jim Fulton wrote:
I plan to do the transition tomorrow, Tuesday may 11.
I'll begin at 10am US/Eastern and be done by 5pm US/Eastern.
During this time, I ask that no one make checkins to the CVS head for those projects. The first thing I will do is to tag the head with the tag: 'cvs-to-svn-conversion'. When I'm done, I will remove all files from the heads of the preojects in CVS, except README.txt files giving subversion access instructions.
Jim
Jim Fulton wrote:
Jim Fulton wrote:
Sorry for the false start.
I totally missed a flaw in subversion's handling of text-file line endings. I suspect that this is fixable, but it's not going to be fixed today.
I think that this issue has been "resolved". I have updated my cvs to svn conversion software to set the svn:eol-style property to "native" on text files so that they will get Windows line endings when checked out on Windows and Unix line endings when checked out on Unix-based systems. I've updated the demonstration repository with the results of this conversion. Note that it's possible that existing checkouts will need to be discarded, as I've totallly rebuilt the repository.
To browse the respository:
To do a read-only checkout:
svn co svn://svn.zope.org/repos/main/<project>/trunk
or, to do a writable checkout:
svn co svn+ssh://svn.zope.org/repos/main/<project>/trunk
Developers who add new files will need to set the svn:eol-style property on new text files. There are ways to automate this and we'll provide some guidence on this at:
http://dev.zope.org/Subversion
BTW, someone has done some work on that Wiki, which was a copy of dev.zope.orf/CVS, to convert the CVS references and instructions to refer to and document Subversion instead. Thanks! I think that there is still a good bit of work to do. Volunteer help would be much appreciated.
I'm thinking of trying again to do the cvs to svn conversion of the main-line development branches (cvs heads) on Tusday May 11. This would entail moving ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig, zdaemon, and zLOG).
Any objections?
Jim
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
The conversion is done. All "trunk" development should be done in the subversion repository for Zope (Zope 2), Zope3, ZODB, ZConfig, and zdaemon. (zLOG is not broken out as a separate project because it's now only used by Zope.) For information on using the Zope subversion repository, see: http://dev.zope.org/Subversion and especially: http://dev.zope.org/Subversion/ZopeSVNFAQ I'm gonna wait a few days before removing files from the CVS head, just to be safe. :) I will check in some marker files, warning people to work in svn. Finally, before the conversion, I tagged the cvs head with the cvs-to-svn-conversion tag. If you have outstanding head work, you should be able to update to that tag and then use cvs diff to generate patch files to be applied to subversion checkouts. Jim Jim Fulton wrote:
I'm about to begin the conversion now. Please don't make any more changes to the Zope, Zope3, ZODB, ZConfig, zLOG, or zdaemon CVS heads.
Jim
Jim Fulton wrote:
I plan to do the transition tomorrow, Tuesday may 11.
I'll begin at 10am US/Eastern and be done by 5pm US/Eastern.
During this time, I ask that no one make checkins to the CVS head for those projects. The first thing I will do is to tag the head with the tag: 'cvs-to-svn-conversion'. When I'm done, I will remove all files from the heads of the preojects in CVS, except README.txt files giving subversion access instructions.
Jim
Jim Fulton wrote:
Jim Fulton wrote:
Sorry for the false start.
I totally missed a flaw in subversion's handling of text-file line endings. I suspect that this is fixable, but it's not going to be fixed today.
I think that this issue has been "resolved". I have updated my cvs to svn conversion software to set the svn:eol-style property to "native" on text files so that they will get Windows line endings when checked out on Windows and Unix line endings when checked out on Unix-based systems. I've updated the demonstration repository with the results of this conversion. Note that it's possible that existing checkouts will need to be discarded, as I've totallly rebuilt the repository.
To browse the respository:
To do a read-only checkout:
svn co svn://svn.zope.org/repos/main/<project>/trunk
or, to do a writable checkout:
svn co svn+ssh://svn.zope.org/repos/main/<project>/trunk
Developers who add new files will need to set the svn:eol-style property on new text files. There are ways to automate this and we'll provide some guidence on this at:
http://dev.zope.org/Subversion
BTW, someone has done some work on that Wiki, which was a copy of dev.zope.orf/CVS, to convert the CVS references and instructions to refer to and document Subversion instead. Thanks! I think that there is still a good bit of work to do. Volunteer help would be much appreciated.
I'm thinking of trying again to do the cvs to svn conversion of the main-line development branches (cvs heads) on Tusday May 11. This would entail moving ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig, zdaemon, and zLOG).
Any objections?
Jim
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
There is a problem with the public subversion access. The 'svn' urls are currently disabled. 'svn+ssh' urls are still working as is web access. I expect to have this problem resolved today. Jim Jim Fulton wrote:
The conversion is done. All "trunk" development should be done in the subversion repository for Zope (Zope 2), Zope3, ZODB, ZConfig, and zdaemon. (zLOG is not broken out as a separate project because it's now only used by Zope.)
For information on using the Zope subversion repository, see:
http://dev.zope.org/Subversion
and especially:
http://dev.zope.org/Subversion/ZopeSVNFAQ
I'm gonna wait a few days before removing files from the CVS head, just to be safe. :)
I will check in some marker files, warning people to work in svn.
Finally, before the conversion, I tagged the cvs head with the cvs-to-svn-conversion tag. If you have outstanding head work, you should be able to update to that tag and then use cvs diff to generate patch files to be applied to subversion checkouts.
Jim
Jim Fulton wrote:
I'm about to begin the conversion now. Please don't make any more changes to the Zope, Zope3, ZODB, ZConfig, zLOG, or zdaemon CVS heads.
Jim
Jim Fulton wrote:
I plan to do the transition tomorrow, Tuesday may 11.
I'll begin at 10am US/Eastern and be done by 5pm US/Eastern.
During this time, I ask that no one make checkins to the CVS head for those projects. The first thing I will do is to tag the head with the tag: 'cvs-to-svn-conversion'. When I'm done, I will remove all files from the heads of the preojects in CVS, except README.txt files giving subversion access instructions.
Jim
Jim Fulton wrote:
Jim Fulton wrote:
Sorry for the false start.
I totally missed a flaw in subversion's handling of text-file line endings. I suspect that this is fixable, but it's not going to be fixed today.
I think that this issue has been "resolved". I have updated my cvs to svn conversion software to set the svn:eol-style property to "native" on text files so that they will get Windows line endings when checked out on Windows and Unix line endings when checked out on Unix-based systems. I've updated the demonstration repository with the results of this conversion. Note that it's possible that existing checkouts will need to be discarded, as I've totallly rebuilt the repository.
To browse the respository:
To do a read-only checkout:
svn co svn://svn.zope.org/repos/main/<project>/trunk
or, to do a writable checkout:
svn co svn+ssh://svn.zope.org/repos/main/<project>/trunk
Developers who add new files will need to set the svn:eol-style property on new text files. There are ways to automate this and we'll provide some guidence on this at:
http://dev.zope.org/Subversion
BTW, someone has done some work on that Wiki, which was a copy of dev.zope.orf/CVS, to convert the CVS references and instructions to refer to and document Subversion instead. Thanks! I think that there is still a good bit of work to do. Volunteer help would be much appreciated.
I'm thinking of trying again to do the cvs to svn conversion of the main-line development branches (cvs heads) on Tusday May 11. This would entail moving ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig, zdaemon, and zLOG).
Any objections?
Jim
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
There is a problem with the public subversion access. The 'svn' urls are currently disabled. 'svn+ssh' urls are still working as is web access. I expect to have this problem resolved today.
This has been resolved. 'svn' urls are enabled again. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (12)
-
Barry Warsaw -
Chris McDonough -
Chris Withers -
Fred Drake -
Jim Fulton -
Lennart Regebro -
Leonardo Rochael Almeida -
Max M -
Paolo Invernizzi -
Stefan H. Holek -
Tim Peters -
Tres Seaver