Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
There are several issues with SVN that I'd like to report:
1) If I drag and drop a folder from a project under version control to another project under version control, i.e. it's doing a MOVE operation, it fails with an exception. I don't have the exception at this time as this occurred this past Sunday when this site was not available.
2) If I delete a folder with several classes (files) also being deleted, I then try to "commit" the project it fails because the folder being deleted is then out of date.
3) If I try to commit at the solution node (top level) it only commits projects within that folder hierarchy and below, my additional projects that are in other locations on the hard drive have to be committed independently.
I also suggest a name change in the version control menu from "update" to "Get Latest" as it better indicates a pull operation retrieving the latest information from source control. The "update" verb implies publishing something, i.e. uploading so it's a bit confusing and concerning. I also suggest "commit" be changed to "check-in", these are terms I'm more accustomed to within VS 2010 (SourceGear Vault is what I use but should be the same as others).
Hey, I'm just looking through these issues at the moment:
1) My guess is that MonoDevelop does not handle the case when a directory from svn repo A in project A is moved to svn repo B in project B. This is a complicated problem aswell as technically it would require deleting the files from the repo A and then adding them as new files under repo B. Does this sound like what you're doing? Or are you moving files/dirs within the same repository?
2) I can't test this. How exactly are you hitting this bug? I've created files in directories, committed them, modified them and committed them, then deleted the entire directory and committed that. It works fine for me with the development versions of MonoDevelop I have.
3) I think what you're saying is that when you do a 'commit' operation in MonoDevelop, it scans the filesystem for changed files instead of scanning the project structure in MonoDevelop and listing changed files. As such, if the project structure does not match the layout of the files on your harddrive, some changed files are not picked up. Is this correct?
Re #1 - There is only one repository, it's moving across projects within a solution all in the same repository. It may not be in the same SVN nesting (folder structure) as I may have a solution set up as:
-Project 1 located in /Dev/App/MainApp
-Project 2 located in /Dev/App/MainApp/MonoTouch.Dialog
-Project 3 located in /Dev/Extensions
Re: #2 - I simply delete the folder and contents I believe is what I did and it wouldn't commit. I have to delete folder contents, commit, then the folder, then commit
Re #3 - this was answered in another bug report and is a problem, if my folder structure is as listed above under #1 it won't commit as there are projects above the root of the solution. I proposed that when you commit a solution it should send a commit command to each project independently and then it won't fail or depend on the folder structure.
Perfect, that's exactly the info I needed. I may still need more info to reproduce issue #2 though. If you can create a small test project which I can use to reproduce the issue that'd be perfect. I have a few ideas on how I might trigger it so I'll give them a shot too.
I'd like to add another problem, which is very much related to (3).
If the filestructure is
and you select commit in libproject, then everything in filesystem folders below is commited as well, even tough it might be contained in a different project.
The remaining issues (the one in comment 4 and the third point in your original report) are because currently MonoDevelop interacts with the version control system at the filesystem level instead of at the project level. Modifying this is will take quite a while. I opened bug #2479 to track those changes and am going to close this now as the other issues you've mentioned have been resolved.