[Python-Dev] Freezing the CVS on Oct 26 for SVN switchover

[Tim Peters]

[skip at 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
>
> http://www.python.org/dev/svn.html

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).