[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Handling failures

From: Paramjit Oberoi <p_s_oberoi_at_hotmail.com>
Date: 2003-07-19 07:04:56 CEST

I just started using svn regularly, and I really like it so far.

Two issues that I encountered:

* If a checkout fails (for instance, because of an incorrectly specified
  no new files/directories should be created. For instance, if I do:

    svn co file:///svn-repository/my-cool-projcet/module1

  (and the repository does not contain "my-cool-projcet") an empty directory
  called "module1" is created with a .svn subdirectory. So I cannot simply
  reissue the checkout command with the corrected spelling---I must first
  delete the bogus directory, otherwise subversion complains that the
  "module1" directory is already a working copy for a different path.

* Accessing a remote repository via ra_svn should check if the same
  subversion version is installed on both ends; otherwise the repository
  can sometimes end up in an unusable state. I had this problem a few times
  before I realized what I was doing wrong. (I know ra_svn is supported only
  the same version of subversion is installed on both ends, but, this should
  explicitly checked. It is somewhat scary to not be able to access the
  after doing a remote commit which seemed to succeed without problems).

  For similar reasons, any tool accessing the repository should check a
  number and refuse to work if the repository format is too old (I had
  of "svn list" terminating with "bus error" when I tried to access a really

I realize these are not even beta releases... but, given that data integrity
is one of
the central requirements, version number checking is really important.


STOP MORE SPAM with the new MSN 8 and get 2 months FREE*

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 19 07:20:40 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.