Bug 2038 - Numerous issues with SVN/Version Control
Summary: Numerous issues with SVN/Version Control
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Version Control ()
Version: 2.8.2
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Alan McGovern
URL:
Depends on:
Blocks:
 
Reported: 2011-11-15 14:09 UTC by Neal
Modified: 2011-12-13 10:23 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 Neal 2011-11-15 14:09:53 UTC
Hello,

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).

Thank you.
Comment 1 Alan McGovern 2011-12-05 12:45:46 UTC
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?
Comment 2 Neal 2011-12-05 14:51:38 UTC
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:

Root SLN
-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.
Comment 3 Alan McGovern 2011-12-05 15:11:22 UTC
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.
Comment 4 Mathias 2011-12-09 06:00:58 UTC
I'd like to add another problem, which is very much related to (3).

If the filestructure is

/libproject
/libproject/testproject

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.
Comment 5 Alan McGovern 2011-12-13 10:23:59 UTC
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.