Freezing the CVS on Oct 26 for SVN switchover
I'd like to start the subversion switchover this coming Wednesday, with a total commit freeze at 16:00 GMT. If you have larger changes to commit that you would like to commit before the switchover, but after that date, please let me know. At that point, I will set the repository to read-only (through a commitinfo hook), and request that SF rolls a tarfile. I will then notify you when the Subversion repository is online. If you have sandboxes with modifications, it might be good to cvs diff -u them now. I plan to keep the CVS up for a short while after the switchover (about a month); after that point, you will need to get the CVS tarball and retarget your sandbox to perform diffs. I'm not aware of a procedure to convert a CVS sandbox into an SVN one, so you will have to recheckout all your sandboxes after the switch. Regards, Martin
"Martin v. Löwis" <martin@v.loewis.de> writes:
I'd like to start the subversion switchover this coming Wednesday, with a total commit freeze at 16:00 GMT.
Yay! Thanks again for doing this. Cheers, mwh -- [Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski
Can anyone point an old CVS/Perforce-Luddite at instructions for how to use the new SVN repository? Jeremy On 10/23/05, Michael Hudson <mwh@python.net> wrote:
"Martin v. Löwis" <martin@v.loewis.de> writes:
I'd like to start the subversion switchover this coming Wednesday, with a total commit freeze at 16:00 GMT.
Yay! Thanks again for doing this.
Cheers, mwh
-- [Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
Jeremy> Can anyone point an old CVS/Perforce-Luddite at instructions for Jeremy> how to use the new SVN repository? Jeremy, I'd never used Subversion until Barry grabbed the python.org web maintainers by our collective ears and dragged us to the table with the kool aid. As it turns out, the svn flavored kool aid tastes about the same as the cvs flavor (svn {commit,up,diff} == cvs {commit,up,diff}, though there are some slight aftertastes you have to get used to (e.g., revision numbers are for the entire branch, not just a single file). That said, the best place to start is probably the Subversion book, available in both online and dead tree versions: http://svnbook.red-bean.com/ Appendix A of that book is "Subversion for CVS Users". Probably worth a quick skim and a browser bookmark. Though there's no svn/cvs cheatsheet there, you may also find isolated tidbits in the Subversion FAQ: http://subversion.tigris.org/faq.html Just grep around for "cvs". Skip
skip@pobox.com wrote:
Though there's no svn/cvs cheatsheet there, you may also find isolated tidbits in the Subversion FAQ:
http://subversion.tigris.org/faq.html
Just grep around for "cvs".
In addition, you might want to read http://www.python.org/dev/svn.html Regards, Martin
[skip@pobox.com]
Though there's no svn/cvs cheatsheet there, you may also find isolated tidbits in the Subversion FAQ:
http://subversion.tigris.org/faq.html
Just grep around for "cvs".
[Martin v. Löwis]
In addition, you might want to read
Excellent suggestions! I have a few to pass on: 1. CVS uses "update" for all sorts of things. SVN has different commands for several of the use cases CVS's update conflates: - Updating to the current server state. "svn update" does that, and SVN's update isn't useful for anything other than that. - Finding out what's changed in your sandbox. Use "svn status" for that. Bonus: in return for creating zillions of admin files, "svn status" is a local operation (no network access required). Do "svn status -u" to get, in addition, a listing of files that _would_ change if you were to do "svn update". - Merging. Use "svn merge" for that. This includes the case of reverting a checkin, in which case just reverse the revision numbers: svn merge URL -rNEW:OLD where NEW is the revision number of the checkin you want to revert, and OLD is typically NEW-1. Very nice: this reverts _all_ changes made in revision NEW, no matter how many files were involved. 2. Every checkin conceptually creates a new version of the entire repository, uniquely identified by its revision number. This is very powerful, but subtle, and CVS has nothing like it. A glimpse of its power was given just above, talking about the ease of reverting an entire checkin in one easy gulp, 3. You're working on a trunk sandbox and discover it's going to take longer than you hoped. Now you wish you had created a branch. This is actually dead easy: create a new branch of the trunk. "svn switch" your sandbox to that new branch; this leaves your local change alone, which is key. "svn commit" -- you're done! There's now a branch on the server matching your fiddled local state. 4. Making a branch or tag goes very fast under SVN. Because branches and tags are just conventionally-named directories, you can delete them (like any other directory) when you're done with them. These conspire to make simple applications of branches much more pleasant than under CVS. 5. CVS uses text mode for files by default. SVN uses binary mode. The latter is safer, but creates endless low-level snags for x-platform development. I encourage Python developers to include this gibberish in their SVN config file: """ [auto-props] # Setting eol-style to native on all files is a trick: if svn # believes a new file is binary, it won't honor the eol-style # auto-prop. However, svn considers the request to set eol-style # to be an error then, and if adding multiple files with one # svn "add" cmd, svn will stop adding files after the first # such error. A future release of svn will probably consider # this to be a warning instead (and continue adding files). * = svn:eol-style=native *.c = svn:keywords=Id *.h = svn:keywords=Id *.py = svn:keywords=Id """ Then SVN will set the necessary svn:eol-style property to "native" on new text files you commit. I've never yet seen it tag a file inappropriately using this trick, but it's guaranteed to screw up _all_ text files without something like this (unless you have the patience and discipline to manually set eol-style=native on all new text files you add).
Hello! On Fri, Oct 28, 2005 at 09:29:09PM -0400, Tim Peters wrote:
- Finding out what's changed in your sandbox. Use "svn status"
svn diff uses locally saved copies of files. This increases speed by trading for the disk space. It also decreases net traffic; that's important for those who have expensive connections.
4. Making a branch or tag goes very fast under SVN.
Fast and cheap in terms of space; Subversion uses a kind of symlinks in its internal filesystem.
make simple applications of branches much more pleasant than under CVS.
Much more pleasant. I now use more branches than I did with CVS and have less conflicts.
* = svn:eol-style=native
I would very much like to recommend developers to set svn:executable property on executable scripts and unset it on non-executable files; thus all those README and NEWS will be tarred with -rw-r--r-- attributes. :) Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Friday 28 October 2005 21:29, Tim Peters wrote:
- Finding out what's changed in your sandbox. Use "svn status" for that. Bonus: in return for creating zillions of admin files, "svn status" is a local operation (no network access required). Do "svn status -u" to get, in addition, a listing of files that _would_ change if you were to do "svn update".
It's worth noting that "svn status -u" does require network access, since it has to check with the repository to see what's been updated there. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
Tim> Excellent suggestions! I have a few to pass on: ... Tim, Thanks for the tips. As a new svn user myself, I find these helpful. These are precisely the things the Wiki would be good for. They don't prescribe policy. They help people in a general way to migrate from cvs to svn more easily. Anyone with cvs and svn experience, but without the ability to check stuff into the pydotorg repository could contribute. Skip
Tim> Excellent suggestions! I have a few to pass on: skip> These are precisely the things the Wiki would be good for. I went ahead and used Tim's note as the basis for a page on the wiki: http://wiki.python.org/moin/CvsToSvn It's linked from the PythonDevelopers page (a page of previously dubious necessity). Skip
skip@pobox.com wrote:
I went ahead and used Tim's note as the basis for a page on the wiki:
http://wiki.python.org/moin/CvsToSvn
It's linked from the PythonDevelopers page (a page of previously dubious necessity).
I have pretty much the same reservations against Wikis as Brett does; it seems more productive if people would just use python-dev to ask questions of the "how do I" kind (and probably of the "do I really need to" kind as well). I don't mind somebody collecting this information into whatever place more permanent and accessible than a mailing list archive; I think I would normally add them to the developer FAQ instead of to the Wiki, primarily because I can memorize the location of the FAQ better. Regards, Martin
Help! What's the magic to get $Revision$ and $Date$ to be expanded upon checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the latter has the svn revision and date in the headers, while the former still has Brett's original revision 1.5 and a date somewhere in June. I tried to fix this by rewriting the fields as $Revision$ and $Date$ but that doesn't seem to make a difference. Googling for this is a bit tricky because Google collapses $Revision and Revision, which makes any query for svn and $Revision rather non-specific. :-( It's also not yet in our Wiki. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
Help!
What's the magic to get $Revision$ and $Date$ to be expanded upon checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the latter has the svn revision and date in the headers, while the former still has Brett's original revision 1.5 and a date somewhere in June. I tried to fix this by rewriting the fields as $Revision$ and $Date$ but that doesn't seem to make a difference.
Googling for this is a bit tricky because Google collapses $Revision and Revision, which makes any query for svn and $Revision rather non-specific. :-( It's also not yet in our Wiki.
You have to set the `svn:keywords` property on each file for which you want these kinds of expansions: http://svnbook.red-bean.com/en/1.0/ch07s02.html#svn-ch-7-sect-2.3.4 Use svn propedit svn:keywords path/to/file to set that property to what you want. Looking at your examples, C:\Code>svn proplist -v http://svn.python.org/projects/peps/trunk/pep-0343.txt Properties on 'http://svn.python.org/projects/peps/trunk/pep-0343.txt': svn:keywords : Author Date Id Revision svn:eol-style : native So that has svn:keywords set, and expansion occurs. OTOH, C:\Code>svn proplist -v http://svn.python.org/projects/peps/trunk/pep-0352.txt Nada -- that one doesn't even have svn:eol-style set. See http://wiki.python.org/moin/CvsToSvn section "File Modes" for how to convince SVN to automatically set the properties you want on new files you commit (unfortunately, each developer has to do this in their own SVN config file).
[Guido van Rossum]
What's the magic to get $Revision$ and $Date$ to be expanded upon checkin?
Expansion does not occur on checkin, but on checkout, and even then, only in your copy -- that one you see (the internal Subversion copy is untouched). You have to edit a property for the file where you want substitutions. That property is named "svn:keywords" and its value decides which kind of substitution you want to allow. This is all theory for me, I never used them. -- François Pinard http://pinard.progiciels-bpi.ca
Guido van Rossum wrote:
Help!
What's the magic to get $Revision$ and $Date$ to be expanded upon checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the latter has the svn revision and date in the headers, while the former still has Brett's original revision 1.5 and a date somewhere in June. I tried to fix this by rewriting the fields as $Revision$ and $Date$ but that doesn't seem to make a difference.
Googling for this is a bit tricky because Google collapses $Revision and Revision, which makes any query for svn and $Revision rather non-specific. :-( It's also not yet in our Wiki.
It's an svn property associated with the file. The property name is svn:keywords, and the value is a space separated list of keywords you'd like to have substituted. Like this: svn propset svn:keywords "Date Revision" ...file list... The list of keywords it will handle is LastChangedDate (or Date) LastChangedRevision (or Revision or Rev) LastChangedBy (or Author) HeadURL (or URL) Id Gary Herron
Jeremy Hylton wrote:
Can anyone point an old CVS/Perforce-Luddite at instructions for how to use the new SVN repository?
And can you remind us where to send our public keys? :) 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> And can you remind us where to send our public keys? :) Jim, Send your keys to pydotorg@python.org. Unless you specify otherwise, your login will probably be "jim.fulton". Skip
On Thursday 27 October 2005 12:07, skip@pobox.com wrote:
Send your keys to pydotorg@python.org. Unless you specify otherwise, your login will probably be "jim.fulton".
Mail to pydotorg doesn't allow posting from non-members; I watch for notifications for owner on that list and try to approve as quickly as possible, but it's a manual process just to get the mail through. We should probably have a dedicated address for this, or tell people to send them to webmaster. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
Fred L. Drake, Jr. wrote:
Mail to pydotorg doesn't allow posting from non-members; I watch for notifications for owner on that list and try to approve as quickly as possible, but it's a manual process just to get the mail through.
Ah, didn't know this.
We should probably have a dedicated address for this, or tell people to send them to webmaster.
I think I would request a separate address; I don't think I want to get all webmaster email. That address should probably include webmaster, though. Regards, Martin
On Thursday 27 October 2005 14:16, Martin v. Löwis wrote:
I think I would request a separate address; I don't think I want to get all webmaster email.
I like the idea of a separate address as well.
That address should probably include webmaster, though.
Are you suggesting that the key-deposit address be routed to the webmaster crew? Most of the webmasters don't have the access needed to deposit keys. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
Fred> Are you suggesting that the key-deposit address be routed to the Fred> webmaster crew? Most of the webmasters don't have the access Fred> needed to deposit keys. In fact, many of us on the pydotorg list don't have ssh access either. I suspect the number of useful recipients is no more than five (Martin, Barry, Anthony, Sean, maybe one or two others). Skip
Fred L. Drake, Jr. wrote:
On Thursday 27 October 2005 14:16, Martin v. Löwis wrote:
I think I would request a separate address; I don't think I want to get all webmaster email.
I like the idea of a separate address as well.
Perhaps the radically named svnaccess@python.org? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com
Jim Fulton wrote:
Can anyone point an old CVS/Perforce-Luddite at instructions for how to use the new SVN repository?
And can you remind us where to send our public keys? :)
pydotorg@python.org should work; you will get a confirmation when they are installed. Regards, Martin
participants (12)
-
"Martin v. Löwis" -
François Pinard -
Fred L. Drake, Jr. -
Gary Herron -
Guido van Rossum -
Jeremy Hylton -
Jim Fulton -
Michael Hudson -
Nick Coghlan -
Oleg Broytmann -
skip＠pobox.com -
Tim Peters