Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-2505

Broken WC with switch, unversioned files, and moves

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: 1.7.0
    • Component/s: libsvn_wc
    • Labels:
      None

      Description

      Repro:
      
      #!/bin/sh
      URL=http://svn.apache.org/repos/asf/httpd/mod_mbox
      svn co -r378000 $URL/trunk mmbxtest
      touch mmbxtest/module-2.0/unversioned
      svn sw -r378000 $URL/branches/surgery mmbxtest
      
      produces error:
      
      subversion/libsvn_wc/update_editor.c:886: (apr_err=155000)
      svn: Won't delete locally modified directory 'mmbxtest'
      subversion/libsvn_wc/adm_ops.c:2061: (apr_err=155012)
      svn: Left locally modified or unversioned files
      
      and leaves the WC in a broken state:
      
      $ svn up mmbxtest 
      subversion/libsvn_wc/lock.c:826: (apr_err=155005)
      svn: Directory 'mmbxtest/module-2.0/.svn' containing working copy admin area is
      missing
      

        Issue Links

          Activity

          Hide
          subversion-importer Subversion Importer added a comment -

          This appears to be a duplicate of an issue I raised a couple of months back.
          Issue  No: 2466.
          
          http://subversion.tigris.org/issues/show_bug.cgi?id=2466 
          
          In 2466, the issue occurred when switching back to trunk from a feature branch
          that had a new directory that contained svn:ignored build output.  
          

          Original comment by matt_doran

          Show
          subversion-importer Subversion Importer added a comment - This appears to be a duplicate of an issue I raised a couple of months back. Issue No: 2466. http://subversion.tigris.org/issues/show_bug.cgi?id=2466 In 2466, the issue occurred when switching back to trunk from a feature branch that had a new directory that contained svn:ignored build output. Original comment by matt_doran
          Hide
          ehuelsmann Erik Huelsmann added a comment -

          *** Issue 2466 has been marked as a duplicate of this issue. ***
          

          Show
          ehuelsmann Erik Huelsmann added a comment - *** Issue 2466 has been marked as a duplicate of this issue. ***
          Hide
          glasser David Glasser added a comment -

          Please do note that 2466 contains a very short reproduction recipe (starting
          from a new repository) for this.
          

          Show
          glasser David Glasser added a comment - Please do note that 2466 contains a very short reproduction recipe (starting from a new repository) for this.
          Hide
          subversion-importer Subversion Importer added a comment -

          This is an issue if projects use branches and svn switch is desired to be used
          instead of checking out from repository (to make moving to work on another
          branch faster).  
          
          I am interested in polling people to see if this bug should be higher priority?  
          
          Also I think this issue should be documented in FAQ and/or manual.
          Essentially a svn switch for us is only possible from a ''pristine'' clean 
          copy of a checkout.
          
          more details here:
          http://svn.haxx.se/users/archive-2007-07/0276.shtml
          
          
          

          Original comment by gaoithe

          Show
          subversion-importer Subversion Importer added a comment - This is an issue if projects use branches and svn switch is desired to be used instead of checking out from repository (to make moving to work on another branch faster). I am interested in polling people to see if this bug should be higher priority? Also I think this issue should be documented in FAQ and/or manual. Essentially a svn switch for us is only possible from a ''pristine'' clean copy of a checkout. more details here: http://svn.haxx.se/users/archive-2007-07/0276.shtml Original comment by gaoithe
          Hide
          dhlocker Donald H Locker added a comment -

          This would seem to me to be a good candidate for a --dry-run type of behaviour,
          or  a verification step before actually attempting to execute the switch.
          
          An error message of "can't switch - [files/directories list here] would be lost
          or damaged" would be very useful.  As it is, I have to look at all the bits I
          know have changed and figure out how to set them aside/protect them, do the
          switch and restore them.  Not so bad with ignored or unversioned artifacts, but
          added and renamed bits are a pain.
          
          I'm not familiar with the internal operations of svn, so these ideas may be
          totally impractical.
          

          Show
          dhlocker Donald H Locker added a comment - This would seem to me to be a good candidate for a --dry-run type of behaviour, or a verification step before actually attempting to execute the switch. An error message of "can't switch - [files/directories list here] would be lost or damaged" would be very useful. As it is, I have to look at all the bits I know have changed and figure out how to set them aside/protect them, do the switch and restore them. Not so bad with ignored or unversioned artifacts, but added and renamed bits are a pain. I'm not familiar with the internal operations of svn, so these ideas may be totally impractical.
          Hide
          subversion-importer Subversion Importer added a comment -

          After delving into this more I am beginning to think this situation is 
          always recoverable from. Error is not great so user is confused though and
          may do wrong thing resulting in broken working copy.
          
          e.g. recipe in bug 2466 did an svn revert after the error.
          This seems to have been the wrong thing, a remove of the unversioned items
          would have recovered the problem. 
          
          Is there another bug here though that an svn revert on a half-switched working
          copy can result in a b0rked working copy?
          
          
          Move dir recipe:
          
          If any directory has been moved or renamed between the branches then
          anything unversioned in there will cause a problem.
          svn plays it safe and doesn't want to delete it.
          
          Fix this by changing error to report full path of directory and direct user
          to remove it out of the way. Or it would be nice if there was a something like
          an --allow-delete-unversioned flag or option which would make svn brutally 
          delete things in the way of a switch.
          
          
          http://subversion.tigris.org/issues/show_bug.cgi?id=2505
          
          wc/$ svn switch $SVNROOT/foobar/branches/br1
          wc/$ mkdir foo
          wc/$ svn add foo
          wc/$ svn ci -m"add dir foo" foo
          wc/$ touch foo/unversioned_file
          wc/$ svn switch $SVNROOT/foobar/branches/br2
          svn: Won't delete locally modified directory '.'
          svn: Left locally modified or unversioned files
          wc/$ svn status 
          !      .
              S  foo.c
          ~      foo
          
          
          It is possible to recover from this. You have a half-switched working copy.
          You can rm the directory left behind (now also unversioned without .svn) and
          then run the svn switch again.
          
          If multiple things have been renamed the switch will trip up and break on each
          one so cleaning out ALL unversioned files helps.
          
          alias svn-unversioned='svn status --no-ignore | grep "^[I?]" | sed 's/^[I?]//''
          alias svn-clean-wc='svn-unversioned |xargs rm -rf'
          
          

          Original comment by gaoithe

          Show
          subversion-importer Subversion Importer added a comment - After delving into this more I am beginning to think this situation is always recoverable from. Error is not great so user is confused though and may do wrong thing resulting in broken working copy. e.g. recipe in bug 2466 did an svn revert after the error. This seems to have been the wrong thing, a remove of the unversioned items would have recovered the problem. Is there another bug here though that an svn revert on a half-switched working copy can result in a b0rked working copy? Move dir recipe: If any directory has been moved or renamed between the branches then anything unversioned in there will cause a problem. svn plays it safe and doesn't want to delete it. Fix this by changing error to report full path of directory and direct user to remove it out of the way. Or it would be nice if there was a something like an --allow-delete-unversioned flag or option which would make svn brutally delete things in the way of a switch. http://subversion.tigris.org/issues/show_bug.cgi?id=2505 wc/$ svn switch $SVNROOT/foobar/branches/br1 wc/$ mkdir foo wc/$ svn add foo wc/$ svn ci -m"add dir foo" foo wc/$ touch foo/unversioned_file wc/$ svn switch $SVNROOT/foobar/branches/br2 svn: Won't delete locally modified directory '.' svn: Left locally modified or unversioned files wc/$ svn status ! . S foo.c ~ foo It is possible to recover from this. You have a half-switched working copy. You can rm the directory left behind (now also unversioned without .svn) and then run the svn switch again. If multiple things have been renamed the switch will trip up and break on each one so cleaning out ALL unversioned files helps. alias svn-unversioned='svn status --no-ignore | grep "^[I?]" | sed 's/^[I?]//'' alias svn-clean-wc='svn-unversioned |xargs rm -rf' Original comment by gaoithe
          Hide
          subversion-importer Subversion Importer added a comment -

          and another recipe:
          
          This is slightly harder to recover from.
          This is definately a situation we were encountering.
          User is directed to cleanup but cleanup doesn't work. 
          Using TortoiseSVN or svn command-line.
          
          Cleaning repository manually before switch or even after switch error recovers
          this situation. IF you clean the right things.
          
          Realistic situation if a temporary build file is accidentally checked in and
          removed.
          From then on a svn switch after build that generates that temp file will encounter
          this situation.
          
          1. using TortoiseSVN to do switch:
          
          Error: Won't delete locally modified directory
          'C:\cygwin\home\james_coleman\checkedout\quantiqa-718\source\ticket'  
          Error: Left locally modified or unversioned files  
          
          Little yellow exclaimation mark warning. on offending file/dirs
          
          2. svn-unversioned |xargs rm -rf  #(or remove by hand)
          
          3. then switch again:
          
          Error: Directory
          'C:\cygwin\home\james_coleman\checkedout\quantiqa-718\source\ticket\ticketgen\.svn'
          containing working copy admin area is missing  
          Error: Please execute the "Cleanup" command.  
          
          okay. Command-line can't switch either.
          
          
          4. TortoiseSVN cleanup:
          
          Error reported in pop-up dialog. A bit differently to other errors:
          
          Subversion reported an error while doing a cleanup!
          source/<dir>/<yetanotherdir> is not a working copy directory
          
          svn-unversioned doesn't see anything
          
          $ svn status
          ! L    .
          ! L    source
          ! L    source/<dir>
              S  source/<dir>/<otherdir>
          ~      source/<dir>/<yetanotherdir>
          
          $ svn-unversioned
          
          $ ls source/<dir>/<yetanotherdir>
          <file>.o
          
          5. At this point the user is not sure what to do.
             They might try a revert which seems to cause trouble.
             The correct thing to do is to Remove that manually
          
          $ rm -rf source/<dir>/<yetanotherdir>
          
          6. Then TortoiseSVN cleanup and then switch successful
          
          
          
          This is because at one time the object file was checked in by accident.
          It was removed but now an svn switch doesn't like deleting it decause of history.
          
          
          
          wc/$ touch br/foo.o
          wc/$ svn add  br/foo.o
          A         br/foo.o
          wc/$ svn ci -m "oops - commit foo.o by accident" br/foo.o
          Adding         br/foo.o
          Transmitting file data .
          Committed revision 20.
          wc/$ svn rm br/foo.o
          D         br/foo.o
          wc/$ svn ci -m "unversion foo.o (committed by accident)" br/foo.o
          Deleting       br/foo.o
          
          Committed revision 21.
          wc/$ touch br/foo.o
          
          ## now try switch
          
          wc/$ svn switch $SVNROOT/$project/branches/br1
          svn: Won't delete locally modified directory '.'
          svn: Left locally modified or unversioned files
          
          
          ### essence of problem
          ### how do you know from that error you should remove this file:
          
          wc/$ ls br
          foo.o
          
          __ACTUALLY__ now you have to remove directory br to recover
          
          ### nothing to delete anyway:
          wc/$ svn-unversioned  |xargs rm -rf
          
          
          ### user is confused. huh huh huh?
          wc/$ svn switch $SVNROOT/$project/branches/br1
          svn: Directory 'br/.svn' containing working copy admin area is missing
          wc/$ svn cleanup
          svn: 'br' is not a working copy directory
          wc/$ svn switch $SVNROOT/$project/branches/br1
          svn: Working copy '.' locked
          svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
          wc/$ svn cleanup
          svn: 'br' is not a working copy directory
          wc/$ svn switch $SVNROOT/$project/branches/br1
          svn: Working copy '.' locked
          svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
          
          
          ### user might spot and remove this file but in a complex repository
          ### there may have been lots of unversioned files 
          
          wc/$ rm -rf br
          wc/$ svn switch $SVNROOT/$project/branches/br1
          svn: Working copy '.' locked
          svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
          wc/$ svn cleanup
          wc/$ svn switch $SVNROOT/$project/branches/br1
          A    br_moved
          A    br_moved/README
          D    br
           U   .
          Updated to revision 21.
          
          

          Original comment by gaoithe

          Show
          subversion-importer Subversion Importer added a comment - and another recipe: This is slightly harder to recover from. This is definately a situation we were encountering. User is directed to cleanup but cleanup doesn't work. Using TortoiseSVN or svn command-line. Cleaning repository manually before switch or even after switch error recovers this situation. IF you clean the right things. Realistic situation if a temporary build file is accidentally checked in and removed. From then on a svn switch after build that generates that temp file will encounter this situation. 1. using TortoiseSVN to do switch: Error: Won't delete locally modified directory 'C:\cygwin\home\james_coleman\checkedout\quantiqa-718\source\ticket' Error: Left locally modified or unversioned files Little yellow exclaimation mark warning. on offending file/dirs 2. svn-unversioned |xargs rm -rf #(or remove by hand) 3. then switch again: Error: Directory 'C:\cygwin\home\james_coleman\checkedout\quantiqa-718\source\ticket\ticketgen\.svn' containing working copy admin area is missing Error: Please execute the "Cleanup" command. okay. Command-line can't switch either. 4. TortoiseSVN cleanup: Error reported in pop-up dialog. A bit differently to other errors: Subversion reported an error while doing a cleanup! source/<dir>/<yetanotherdir> is not a working copy directory svn-unversioned doesn't see anything $ svn status ! L . ! L source ! L source/<dir> S source/<dir>/<otherdir> ~ source/<dir>/<yetanotherdir> $ svn-unversioned $ ls source/<dir>/<yetanotherdir> <file>.o 5. At this point the user is not sure what to do. They might try a revert which seems to cause trouble. The correct thing to do is to Remove that manually $ rm -rf source/<dir>/<yetanotherdir> 6. Then TortoiseSVN cleanup and then switch successful This is because at one time the object file was checked in by accident. It was removed but now an svn switch doesn't like deleting it decause of history. wc/$ touch br/foo.o wc/$ svn add br/foo.o A br/foo.o wc/$ svn ci -m "oops - commit foo.o by accident" br/foo.o Adding br/foo.o Transmitting file data . Committed revision 20. wc/$ svn rm br/foo.o D br/foo.o wc/$ svn ci -m "unversion foo.o (committed by accident)" br/foo.o Deleting br/foo.o Committed revision 21. wc/$ touch br/foo.o ## now try switch wc/$ svn switch $SVNROOT/$project/branches/br1 svn: Won't delete locally modified directory '.' svn: Left locally modified or unversioned files ### essence of problem ### how do you know from that error you should remove this file: wc/$ ls br foo.o __ACTUALLY__ now you have to remove directory br to recover ### nothing to delete anyway: wc/$ svn-unversioned |xargs rm -rf ### user is confused. huh huh huh? wc/$ svn switch $SVNROOT/$project/branches/br1 svn: Directory 'br/.svn' containing working copy admin area is missing wc/$ svn cleanup svn: 'br' is not a working copy directory wc/$ svn switch $SVNROOT/$project/branches/br1 svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) wc/$ svn cleanup svn: 'br' is not a working copy directory wc/$ svn switch $SVNROOT/$project/branches/br1 svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) ### user might spot and remove this file but in a complex repository ### there may have been lots of unversioned files wc/$ rm -rf br wc/$ svn switch $SVNROOT/$project/branches/br1 svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) wc/$ svn cleanup wc/$ svn switch $SVNROOT/$project/branches/br1 A br_moved A br_moved/README D br U . Updated to revision 21. Original comment by gaoithe
          Hide
          subversion-importer Subversion Importer added a comment -

          To summarise:
          
          I think this could be resolved by changing the error to report the full path of
          the directory and direct user to remove it out of the way. 
          
          And it would be even better if there was a something like an
          --allow-delete-unversioned flag or option which would make svn brutally delete
          things in the way of a switch.
          
          Clients like TortoiseSVN should prompt user to confirm it is okay to delete the
          files/dirs in the way.
          
          And needs to be looked at:
          
          svn cleanup on half-switched working copy should be able to remove the files in
          the way?
          
          behaviour of svn revert on half-switched working copy 
          
          

          Original comment by gaoithe

          Show
          subversion-importer Subversion Importer added a comment - To summarise: I think this could be resolved by changing the error to report the full path of the directory and direct user to remove it out of the way. And it would be even better if there was a something like an --allow-delete-unversioned flag or option which would make svn brutally delete things in the way of a switch. Clients like TortoiseSVN should prompt user to confirm it is okay to delete the files/dirs in the way. And needs to be looked at: svn cleanup on half-switched working copy should be able to remove the files in the way? behaviour of svn revert on half-switched working copy Original comment by gaoithe
          Hide
          subversion-importer Subversion Importer added a comment -

          Abhinandan Jain on users list says this (and I think it makes sense):
           
          To me this looks like an SVN bug rather than a usage error. Virtually
          all other SVN operations (copy, commit, delete et.) simply ignore
          unversioned files that ight be around. I would expect switch to behave
          the same way. At the minimum it would be useful to have an extra
          option to switch to get such consistent behavior instead of insisting
          on users manually clearing out unversioned files.
          
          
          

          Original comment by gaoithe

          Show
          subversion-importer Subversion Importer added a comment - Abhinandan Jain on users list says this (and I think it makes sense): To me this looks like an SVN bug rather than a usage error. Virtually all other SVN operations (copy, commit, delete et.) simply ignore unversioned files that ight be around. I would expect switch to behave the same way. At the minimum it would be useful to have an extra option to switch to get such consistent behavior instead of insisting on users manually clearing out unversioned files. Original comment by gaoithe
          Hide
          ehuelsmann Erik Huelsmann added a comment -

          1.6-consider is the wc-rewrite release?
          

          Show
          ehuelsmann Erik Huelsmann added a comment - 1.6-consider is the wc-rewrite release?
          Hide
          subversion-importer Subversion Importer added a comment -

          I fail to see why 'svn switch' behaves differently from 'svn update -r <N>'.
          Both perform the necessary steps to convert a wc tree to a different wc tree. I
          don't know svn internals but wouldn't it be possible to reuse svn update code?
          Or at least instead of making the switch abort when it can't remove a nonempty
          directory, just let it be ignored and go on, just as svn update does?
          
          I mean:
          
          $ svn status -v --no-ignore
                          5        5 pgimeno      .
          $ mkdir foo
          $ svn add foo
          A         foo
          $ svn commit -m"Adding foo"
          Adding         foo
          
          Committed revision 6.
          $ touch foo/foo.o
          $ svn update -r 5
          D    foo
          Updated to revision 5.
          $ svn status
          ?      foo
          $ ls foo
          foo.o
          $
          
          That's what svn update does, which is for some reason different to what svn
          switch does. The wc remains stable. Shouldn't svn switch behave the same?
          
          

          Original comment by pgimeno

          Show
          subversion-importer Subversion Importer added a comment - I fail to see why 'svn switch' behaves differently from 'svn update -r <N>'. Both perform the necessary steps to convert a wc tree to a different wc tree. I don't know svn internals but wouldn't it be possible to reuse svn update code? Or at least instead of making the switch abort when it can't remove a nonempty directory, just let it be ignored and go on, just as svn update does? I mean: $ svn status -v --no-ignore 5 5 pgimeno . $ mkdir foo $ svn add foo A foo $ svn commit -m"Adding foo" Adding foo Committed revision 6. $ touch foo/foo.o $ svn update -r 5 D foo Updated to revision 5. $ svn status ? foo $ ls foo foo.o $ That's what svn update does, which is for some reason different to what svn switch does. The wc remains stable. Shouldn't svn switch behave the same? Original comment by pgimeno
          Hide
          cmpilato C. Michael Pilato added a comment -

          > I fail to see why 'svn switch' behaves differently from 'svn update -r <N>'.
          > Both perform the necessary steps to convert a wc tree to a different wc tree. I
          > don't know svn internals but wouldn't it be possible to reuse svn update code?
          
          Switch and Update actually do use basically the same code (both server-side and
          client-side), with some exceptions here and there for dealing with the
          intricacies of changing the repository locations reflected by the working copy
          members.
          

          Show
          cmpilato C. Michael Pilato added a comment - > I fail to see why 'svn switch' behaves differently from 'svn update -r <N>'. > Both perform the necessary steps to convert a wc tree to a different wc tree. I > don't know svn internals but wouldn't it be possible to reuse svn update code? Switch and Update actually do use basically the same code (both server-side and client-side), with some exceptions here and there for dealing with the intricacies of changing the repository locations reflected by the working copy members.
          Hide
          subversion-importer Subversion Importer added a comment -

          It seems to me that svn switch in its current form is broken. I think that it
          should:
          
          1) Perform lookahead on all the directories it will touch to tell whether or not
          it is going to fail due to unversioned files, and if so fail with an error
          message before making ANY changes to the user's working copy
          
          and
          
          2) Ignore unversioned resources as others have suggested above.
          
          It is important that SVN commands be atomic whenever possible, and having a
          command be able to fail "halfway through" and leave junk behind is IMHO
          unacceptable in all cases except for unpredictable errors (such as network
          outages). In the case of errors that can be detected in advance, such as
          unversioned files sitting in a directory, a command should either detect the
          problem and fail before any changes have been made, or it should fail while
          making changes but then roll back the working copy to its original state before
          exiting. In either case, it should definitely not corrupt the user's working
          copy due to a problem that could have been detected before any changes were made.
          
          It is quite irritating, as an administrator of Subversion, to have to keep
          directing users to read the FAQ and execute arcane sets of command-line
          instructions (which, for many users, necessitates finding and installing
          command-line tools, which they may not even have on their systems) for issues
          such as this. This is a case where I think Subversion should "just work" rather
          than failing and leaving things in a broken state as it does now, requiring
          research and manual intervention of an expert user to fix.
          
          

          Original comment by ixchel

          Show
          subversion-importer Subversion Importer added a comment - It seems to me that svn switch in its current form is broken. I think that it should: 1) Perform lookahead on all the directories it will touch to tell whether or not it is going to fail due to unversioned files, and if so fail with an error message before making ANY changes to the user's working copy and 2) Ignore unversioned resources as others have suggested above. It is important that SVN commands be atomic whenever possible, and having a command be able to fail "halfway through" and leave junk behind is IMHO unacceptable in all cases except for unpredictable errors (such as network outages). In the case of errors that can be detected in advance, such as unversioned files sitting in a directory, a command should either detect the problem and fail before any changes have been made, or it should fail while making changes but then roll back the working copy to its original state before exiting. In either case, it should definitely not corrupt the user's working copy due to a problem that could have been detected before any changes were made. It is quite irritating, as an administrator of Subversion, to have to keep directing users to read the FAQ and execute arcane sets of command-line instructions (which, for many users, necessitates finding and installing command-line tools, which they may not even have on their systems) for issues such as this. This is a case where I think Subversion should "just work" rather than failing and leaving things in a broken state as it does now, requiring research and manual intervention of an expert user to fix. Original comment by ixchel
          Hide
          subversion-importer Subversion Importer added a comment -

          It seems to me that svn switch in its current form is broken. I think that it
          should:
          
          1) Perform lookahead on all the directories it will touch to tell whether or not
          it is going to fail due to unversioned files, and if so fail with an error
          message before making ANY changes to the user's working copy
          
          and
          
          2) Ignore unversioned resources as others have suggested above.
          
          It is important that SVN commands be atomic whenever possible, and having a
          command be able to fail "halfway through" and leave junk behind is IMHO
          unacceptable in all cases except for unpredictable errors (such as network
          outages). In the case of errors that can be detected in advance, such as
          unversioned files sitting in a directory, a command should either detect the
          problem and fail before any changes have been made, or it should fail while
          making changes but then roll back the working copy to its original state before
          exiting. In either case, it should definitely not corrupt the user's working
          copy due to a problem that could have been detected before any changes were made.
          
          It is quite irritating, as an administrator of Subversion, to have to keep
          directing users to read the FAQ and execute arcane sets of command-line
          instructions (which, for many users, necessitates finding and installing
          command-line tools, which they may not even have on their systems) for issues
          such as this. This is a case where I think Subversion should "just work" rather
          than failing and leaving things in a broken state as it does now, requiring
          research and manual intervention of an expert user to fix.
          
          

          Original comment by ixchel

          Show
          subversion-importer Subversion Importer added a comment - It seems to me that svn switch in its current form is broken. I think that it should: 1) Perform lookahead on all the directories it will touch to tell whether or not it is going to fail due to unversioned files, and if so fail with an error message before making ANY changes to the user's working copy and 2) Ignore unversioned resources as others have suggested above. It is important that SVN commands be atomic whenever possible, and having a command be able to fail "halfway through" and leave junk behind is IMHO unacceptable in all cases except for unpredictable errors (such as network outages). In the case of errors that can be detected in advance, such as unversioned files sitting in a directory, a command should either detect the problem and fail before any changes have been made, or it should fail while making changes but then roll back the working copy to its original state before exiting. In either case, it should definitely not corrupt the user's working copy due to a problem that could have been detected before any changes were made. It is quite irritating, as an administrator of Subversion, to have to keep directing users to read the FAQ and execute arcane sets of command-line instructions (which, for many users, necessitates finding and installing command-line tools, which they may not even have on their systems) for issues such as this. This is a case where I think Subversion should "just work" rather than failing and leaving things in a broken state as it does now, requiring research and manual intervention of an expert user to fix. Original comment by ixchel
          Hide
          subversion-importer Subversion Importer added a comment -

          Oops. Sorry for the duplicate post above. My finger slipped.
          

          Original comment by ixchel

          Show
          subversion-importer Subversion Importer added a comment - Oops. Sorry for the duplicate post above. My finger slipped. Original comment by ixchel
          Hide
          hwright Hyrum Wright added a comment -

          Post-1.6 issue sweep.  Since 1.7 is already shaping up to be a large release,
          move to 1.8-consider.
          

          Show
          hwright Hyrum Wright added a comment - Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release, move to 1.8-consider.
          Hide
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment -

          The original recipe does not error in 1.7.0-beta1.
          

          Show
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment - The original recipe does not error in 1.7.0-beta1.
          Hide
          rhuijben Bert Huijben added a comment -

          I think most of the original errors were changed for tree conflict handling and 
          in 1.7 all these cases are made non-fatal by applying so called 'shadowed 
          updates'.
          
          The working copy will/should now perform the entire switch but you will have to 
          remove and/or revert the local obstructions to get an unmodified -switched- 
          working copy.
          

          Show
          rhuijben Bert Huijben added a comment - I think most of the original errors were changed for tree conflict handling and in 1.7 all these cases are made non-fatal by applying so called 'shadowed updates'. The working copy will/should now perform the entire switch but you will have to remove and/or revert the local obstructions to get an unmodified -switched- working copy.

            People

            • Assignee:
              Unassigned
              Reporter:
              maxb Max Bowsher
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development