Bug 6557 - [svn17] SVN not tracking nested directories/projects
Summary: [svn17] SVN not tracking nested directories/projects
Status: RESOLVED DUPLICATE of bug 5525
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Version Control ()
Version: 3.0.x
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Alan McGovern
Depends on:
Reported: 2012-08-16 10:34 UTC by Mike
Modified: 2013-01-14 09:38 UTC (History)
2 users (show)

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:

Description Mike 2012-08-16 10:34:11 UTC
I am having an issue where MonoDevelop has suddenly (just on this machine, OpenSuse 12.1 x86-64) decided that it isn't going to keep track of files in sub-directories in subversion. This started 2 days ago, removing and reinstalling subversion and MonoDevelop does not fix the situation. 

I go to Version Control, navigate to my SVN repository and pull a Directory down that contains essentially a solution file, sub-directories that each contain a project file, with files, and further nested directories/files. Once it finishes MonoDevelop sees all files and projects but does not reckognize that anything beyond the Solution File is version controlled. 

I have verified looking in the .svn directory at the sqlite database that all files are being tracked and handled by subversion, so this is definitely a MonoDevelop issue. I have attempted to trick MonoDevelop by using SVN to individual pull each directory down (creating a .svn directory for each one) so when I open the solution in MonoDevelop it sees that the Solution File is Controlled, the Project Files are controlled and all files that are contained in the same directory as the .svn directories. HOWEVER, all nested directories beyond that are not treated as version controlled.

I'm not getting any errors when doing this. As far as I know nothing has really changed in the last 2 days on this machine, and I have an almost identical setup on another machine that doesn't have any issues and is using all the same versions. Any suggestions on how to fix this?
Comment 1 Mike 2012-08-16 10:40:59 UTC
I should note that if i add a project that is version controlled, MonoDevelop is not attempting (anymore) to see if it is version controlled. It just seems to  no longer recourse forwards and backwards (or read the sqlite file correctly, however its done behind the scenes).
Comment 2 Mike 2012-11-14 22:37:27 UTC

I'm consistently running into this issue and mostly appears to be when the files were not originally started on the machine. So for example if i started a new solution and built a bunch of project files and then add them to a SVN repository and pull them back down, they work fine. If I do the same thing on another machine, then pull the repository down on another, i Have this issue.

I'm not sure if its an OpenSuse "specific" problem but as of right now I would consider SVN support broken on a run of the mill OpenSuse 12.x install of MonoDevelop.
Comment 3 Lluis Sanchez 2012-11-15 03:30:32 UTC
The problem is probably that you are using Subversion 1.7, which is not yet fully supported by MD.
Comment 4 Alan McGovern 2013-01-14 09:38:34 UTC

*** This bug has been marked as a duplicate of bug 5525 ***