Bug 7014 - Subversion error when adding new folder
Summary: Subversion error when adding new folder
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Version Control ()
Version: 3.0.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Alan McGovern
Depends on:
Reported: 2012-09-09 06:18 UTC by Jens
Modified: 2012-11-22 06:29 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

example project to show the bug (120.45 KB, application/zip)
2012-09-09 06:18 UTC, Jens

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jens 2012-09-09 06:18:14 UTC
Created attachment 2482 [details]
example project to show the bug

I had a "dataClasses" folder, wanted to remove it and replace it by a "DataClasses" folder. Something probably went wrong and now everytime I want to create a "DataClasses" folder it does it in the filesystem but calls it "new folder" in the project

how to reproduce:
- load the demo project
- in the CoreShared project try to add the "DataClasses" folder
- check in the filesystem: the DataClasses folder was created
- check in the project: a "New Folder" folder was created -> BUG

what did I expect?
- the folder should be called "DataClasses" in the project too
Comment 1 Jens 2012-09-09 07:19:19 UTC
maybe of interest to you: my version informations:

Installation UUID: b4689d2b-e31f-4db7-b0b9-684da039b7d3
	Mono 2.10.9 (tarball)
	GTK 2.24.10
	GTK# (
	Package version: 210090011
Apple Developer Tools:
	 Xcode 4.4.1 (1488)
	 Build 4F1003
Monotouch: 5.4.0
Mono for Android: 4.2.5
Android SDK: /Users/jens-uwe/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.1 (API level 7)
		2.2 (API level 8)
		2.3 (API level 10)
		3.1 (API level 12)
		4.0 (API level 14)
Java SDK: /usr
Build information:
	Release ID: 30004005
	Git revision: 0f7c90e6b2f66983f021120b8a398192ba91589b-dirty
	Build date: 2012-08-31 21:23:19+0000
	Xamarin addins: 75a3c9ec1a014eebf0f8346280ba8d7ad9629d3d
Operating System:
	Mac OS X 10.8.1
	Darwin Jens-Uwes-MacBook-Pro.local 12.1.0 Darwin Kernel Version 12.1.0
	    Tue Aug 14 13:29:55 PDT 2012
	    root:xnu-2050.9.2~1/RELEASE_X86_64 x86_64
Comment 2 Mikayla Hutchinson [MSFT] 2012-09-10 14:18:10 UTC
This looks like a bug in the svn support. MD is swallowing the following error:

ERROR [2012-09-10 14:16:24Z]: MonoDevelop.VersionControl.Subversion.SubversionException: Directory '/Users/michael/Downloads/LetMeTalk/CoreShared/DataClasses/.svn' containing working copy admin area is missing
  at MonoDevelop.VersionControl.Subversion.Unix.SvnClient.CheckError (IntPtr error) [0x0007c] in /Users/michael/Mono/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion.Unix/MonoDevelop.VersionControl.Subversion.Unix/SvnClient.cs:968 
  at MonoDevelop.VersionControl.Subversion.Unix.SvnClient.Add (FilePath path, Boolean recurse, IProgressMonitor monitor) [0x0008a] in /Users/michael/Mono/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion.Unix/MonoDevelop.VersionControl.Subversion.Unix/SvnClient.cs:615 
  at MonoDevelop.VersionControl.Subversion.SubversionRepository.Add (MonoDevelop.Core.FilePath[] paths, Boolean recurse, IProgressMonitor monitor) [0x001b3] in /Users/michael/Mono/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion/SubversionRepository.cs:288 
  at MonoDevelop.VersionControl.Repository.Add (FilePath localPath, Boolean recurse, IProgressMonitor monitor) [0x00000] in /Users/michael/Mono/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl/MonoDevelop.VersionControl/Repository.cs:293 
  at MonoDevelop.VersionControl.Subversion.SubversionRepository.MoveDirectory (FilePath srcPath, FilePath destPath, Boolean force, IProgressMonitor monitor) [0x002d7] in /Users/michael/Mono/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion/SubversionRepository.cs:424 
  at MonoDevelop.VersionControl.VersionControlFileSystemExtension.MoveDirectory (FilePath sourcePath, FilePath destPath) [0x00024] in /Users/michael/Mono/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl/MonoDevelop.VersionControl/VersionControlFileSystemExtension.cs:95 
  at MonoDevelop.Core.FileService.InternalMoveDirectory (System.String srcPath, System.String dstPath) [0x00017] in /Users/michael/Mono/monodevelop/main/src/core/MonoDevelop.Core/MonoDevelop.Core/FileService.cs:229 
  at MonoDevelop.Core.FileService.RenameDirectory (System.String oldName, System.String newName) [0x0001e] in /Users/michael/Mono/monodevelop/main/src/core/MonoDevelop.Core/MonoDevelop.Core/FileService.cs:143 
  at MonoDevelop.Ide.Gui.Pads.ProjectPad.ProjectFolderCommandHandler.RenameItem (System.String newName) [0x0007f] in /Users/michael/Mono/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui.Pads.ProjectPad/ProjectFolderNodeBuilder.cs:160 
  at MonoDevelop.Ide.Gui.Components.ExtensibleTreeView.HandleOnEdit (System.Object o, Gtk.EditedArgs e) [0x000af] in /Users/michael/Mono/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui.Components/ExtensibleTreeView.cs:1244
Comment 3 Alan McGovern 2012-11-22 06:29:23 UTC
ExtensibleTreeView is capturing exceptions and logging them only to the terminal. The actual bug is that we do not propagate the exception information to the user in this scenario. If i extract the attached sample project I can see that when I run svn status from the terminal I see:

D       CoreShared/dataClasses
!       CoreShared/DataClasses

Native SVN is already under the impression that the 'DataClasses' directory has been added to the tree. I don't really know what we can do in this scenario. I'd need to know how the repository got into this state in order to figure out what has gone wrong. As it is, there is not much we can realistically do at this stage other than blindly revert changes in the repository, which is not something I want to do as there's a risk important changes could be lost.

You can recover from this situation by reviewing the repository status and reverting the change which affects the 'CoreShared/DataClasses' path and then just do it again. As such, I'll mark this bug as invalid for now as this does not appear to be a direct MonoDevelop bug, it looks like a weird scenario where we misreport errors. I'll work on fixing the exception propagation though.