Bug 13266 - XS ignores the repo type after a checkout
Summary: XS ignores the repo type after a checkout
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Version Control ()
Version: 4.1
Hardware: PC Mac OS
: --- normal
Target Milestone: master
Assignee: Alan McGovern
URL:
Depends on:
Blocks:
 
Reported: 2013-07-16 04:48 UTC by Paul Johnson
Modified: 2013-07-18 11:40 UTC (History)
3 users (show)

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

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:
Status:
RESOLVED FIXED

Description Paul Johnson 2013-07-16 04:48:21 UTC
I have performed a checkout on a GIT repo, opened it in XS 4.1.6 and made a change. When I come to commit the change, I am met with an error saying

MonoDevelop.VersionControl.Subversion.SubversionException: '/Volumes/Developer/Developer/hellou/api-tests/api-tests/api-tests' is not a working copy
  at MonoDevelop.VersionControl.Subversion.Unix.SvnClient.CheckError (IntPtr error, Nullable`1 allowedError) [0x0009f] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-4.1.6-branch/dc82b708/source/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion.Unix/MonoDevelop.VersionControl.Subversion.Unix/SvnClient.cs:48 
  at MonoDevelop.VersionControl.Subversion.Unix.SvnClient.CheckError (IntPtr error) [0x00001] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-4.1.6-branch/dc82b708/source/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion.Unix/MonoDevelop.VersionControl.Subversion.Unix/SvnClient.cs:26 
  at MonoDevelop.VersionControl.Subversion.Unix.UnixSvnBackend.CheckError (IntPtr error) [0x00001] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-4.1.6-branch/dc82b708/source/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion.Unix/MonoDevelop.VersionControl.Subversion.Unix/SvnClient.cs:171 
  at MonoDevelop.VersionControl.Subversion.Unix.UnixSvnBackend.Status (MonoDevelop.VersionControl.Repository repo, FilePath path, MonoDevelop.VersionControl.Subversion.SvnRevision rev, Boolean descendDirs, Boolean changedItemsOnly, Boolean remoteStatus) [0x00077] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-4.1.6-branch/dc82b708/source/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion.Unix/MonoDevelop.VersionControl.Subversion.Unix/SvnClient.cs:509 
  at MonoDevelop.VersionControl.Subversion.SubversionBackend.GetDirectoryVersionInfo (MonoDevelop.VersionControl.Repository repo, FilePath sourcepath, Boolean getRemoteStatus, Boolean recursive) [0x00007] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-4.1.6-branch/dc82b708/source/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion/SubversionVersionControl.cs:151 
  at MonoDevelop.VersionControl.Subversion.SubversionRepository.OnGetDirectoryVersionInfo (FilePath sourcepath, Boolean getRemoteStatus, Boolean recursive) [0x0000b] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-4.1.6-branch/dc82b708/source/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion/SubversionRepository.cs:101 
  at MonoDevelop.VersionControl.Repository.GetDirectoryVersionInfo (FilePath localDirectory, Boolean getRemoteStatus, Boolean recursive) [0x0001f] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-4.1.6-branch/dc82b708/source/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl/MonoDevelop.VersionControl/Repository.cs:207 
  at MonoDevelop.VersionControl.Views.StatusView.<StartUpdate>m__3 (System.Object ) [0x00019] in /Users/builder/data/lanes/monodevelop-lion-monodevelop-4.1.6-branch/dc82b708/source/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl/MonoDevelop.VersionControl.Views/StatusView.cs:415

The throwback is correct, it's not a working copy for svn. It is though a working copy for git.
Comment 1 Lluis Sanchez 2013-07-17 10:45:18 UTC
This could happen if the directory or any of the parent directories contain a hidden subdirectory named .svn
Comment 2 Paul Johnson 2013-07-17 11:25:09 UTC
The directory was a newly created one so shouldn't have any sort of .svn directory anywhere
Comment 3 Lluis Sanchez 2013-07-17 14:18:39 UTC
Can you check in the parent directories? (up to the root of the disk)
Comment 4 Paul Johnson 2013-07-18 04:17:29 UTC
Very root of the drive had a .svn directory in - removed that and git now works. This leads to the question - why is the very root of the drive being used instead of each project? Surely the type of repo in use should be on a per-project rather than per drive basis.
Comment 5 Lluis Sanchez 2013-07-18 05:42:09 UTC
Starting at version 1.7, Subversion uses a single .svn directory to store al version information, similar to how git does it. When checking if a project is under version control, the Subversion add-in checks if the solution directory has a .svn dir, but if it doesn't find it, it also needs to look in parent directories since the solution might be placed in a subdirectory of the repository. We'll try to improve the repository detection code. We currently only check if the .svn directory exists. We can probably do additional checks to ensure that the .svn really is a repository root.
Comment 6 Marius Ungureanu 2013-07-18 06:42:00 UTC
This has been fixed and will be included in the next release. =D Thanks for the report.