1

I've been using AnkhSVN with VS2010 for development of several projects ("solutions"). For a while my commits have been going fine. But recently, Ankhsvn has changed my repository to one of my projects, so that what should be a child project now duplicates the entire repository structure. This has happened on more that one occasion such that the current project I have to check out is located within another project which itself is within another project. I've gone to File -> Subversion -> Change Source Control but the URL can't be edited. When I try using Pending Changes, I get an errmsg about a broken lock on the working copy. Of course I have tried Clean several times. I also tried Switch which I think got me into more trouble. How did the repo get changed in the first place? Any idea what I did wrong (and how to fix) ?

viejo
  • 123
  • 1
  • 10

1 Answers1

0

What probably happen is that the binding path was changed. You can change this by selecting the solution in File -> Subversion -> Change Source Control, and clicking the ... button. This value is stored in the sln file in the SCC Bindings section.

What happens when checking out the solution, using File -> Open -> Subversion Project, is that it checks out at the level defined by the SCC Binding Path above.

I would also recommend checking out a smaller working copy, because it's much more efficient that way. You're looking to check out at the trunk level (or any branch ofcourse). Checking out above branch means that branching and tagging is suddenly expensive (because each time it happens your working copy grows a lot)

Sander Rijken
  • 21,376
  • 3
  • 61
  • 85
  • I followed your suggestion with a 'non-broken' project first, to see what should occur. When I got to the SCC binding path, the correct URL showed in the drop-down box but clicking on it did not change the existing SCC binding path. On my broken project, I got an Ankhsvn exception when I selected ChangeSourceControl: System.NullReferenceException: Object reference not set to an instance of an object [followed by stack trace]. Yet, I can actually edit this project and save it. – viejo Mar 31 '11 at 14:49
  • About your answer, what do you mean by checking out a 'smaller' working copy? Should the repository be better as a group of small repositories? – viejo Mar 31 '11 at 14:56
  • @Sander (Oops, forgot to notify you. Thanks for your help so far.) – viejo Mar 31 '11 at 16:28
  • I don't recommend splitting up the repository, but you can check out at a deeper level than the repository root, making the working copy (what you have locally) smaller. The normal practice is to check out the trunk (or any tag/branch that you might have) – Sander Rijken Apr 04 '11 at 23:40
  • @viejo: About the NullRef exception, can you submit that through email? It's probably a bug that needs fixing. I'm not sure what might cause the SCC Binding Path to stay the same, even when selecting a different value using the drop down. Can you give more information about your repository and at what level your working copy is? – Sander Rijken Apr 04 '11 at 23:42
  • @Sander: I've submitted the null to a Collabnet forum which seemed to be the proper place for bugs. I have managed to restructure my repository without losing too much history, by exporting and re-adding using tortoisesvn. My repository is a flat structure holding about 20 children. Each child is a project which holds a C# sln and all the associated dirs and files. About half of the children have trunks (I'm the only developer here). Until recently, most of the working copies were located in the VS2010 Projects directory. – viejo Apr 06 '11 at 17:22