Possible to force SVN to consider a directory a working copy?

0
votes

I'm trying to resolve this puzzle and I'm starting to think the problem isn't that SVN clients can't resolve the path to the repository, it's that the repository isn't a working copy.

Summary of original problem: I'm migrating from an old Bitnami Trac Stack on an Ubuntu VM to a current native Windows Bitnami Trac Stack on the same server. I used backups made with hotcopy from the Ubuntu SVN repositories so theoretically they're "indistinguishable" from the those.

However, I am unable to view the new SVN repositories in an external client like TortoiseSVN, but I can view the repositories in Trac. Any command that I run at the command line tells me that the repository I'm trying to work with "is not a working copy".

If I point TortoiseSVN at //sbeut01:8001/svn/RnD (which theoretically is a valid repository) it errors gracefully with: //sbeut01:8001/svn/RnD is not a working copy

How can I make the repositories on the Windows Trac/subversion instance working copies? Or does that appear to be the actual problem as opposed to my original question referred to above?

SO Question that didn't resolve the problem

Edit: I thought I'd try to just make a brand new repository using the Windows Trac/subversion instance, and then see if I could see that instance from a remote svn client or even the local copy. However, if I try to do a svn mkdir c:\test, I get the same error, c:\test is not a working copy. I'm not sure what to make of that. I also tried to do the same with svnadmin create c:\test, with the same results.

2nd Edit It turned out that there actually was a working copy, I was just looking in the wrong place for it. The eventual right answer was:

svn://[IP address]:3691/Bitnami/Repos/RnD

8001 was the Apache port that Trac uses to view a web enabled version of the repository, 3691 is the SVN port from when I first set up the Windows Bitnami Trac Stack

1
svntracbitnami
Terminology may be getting mixed up here. Are you confusing a working copy (result of running svn checkout) with the file location where a repository is stored on disk (result of running svnadmin create)? – Patrick Quirk
I created the repositories by running: c:\bitnami\trac - 1.0.5-0\subversion\bin\hotcopy [path to un-tarred hotcopy backups from Ubuntu] [path to new repository]. My understanding of hotcopy is that should create a new working copy in the new directory. Did that answer your question? – delliottg
hotcopy copies the repository (i.e. what is stored on the server); it does not create a working copy (i.e. what is stored on all the clients). I don't know much about your problem specifically, I just want to make sure your terminology is correct because it really matters. – Patrick Quirk
I wonder why you ask this new question although you've asked already here: stackoverflow.com/questions/29907387/…. Furthermore it's not clear from where your Tortoise should run, on server or client machine, because it does just make sense from a remote client computer, but for enabling that you need to map your repos to network URLs via Apache webserver as already described in my mentioned other SO question. – falkb

1 Answers

1
votes

I think I see what's going on, and it appears that everything is working fine and there's just a little misunderstanding on your end.

Using Tortoise, open a Repository Browser and enter in your repository location, but keep the http protocol identifier on it, i.e. http://sbeut01:8001/svn/RnD. Assuming everything is set up correctly, which it sounds to me like it is since you say Trac can see it there, you'll see your repository as you'd expect.

The problem you were running into it just a misunderstanding of how Tortoise and SVN in general work, I believe. Tortoise can communicate with both the repository (on the server) and the working copy (on the client). It's not immediately obvious all the time which Tortoise operation is communicating with which, and without experience or the knowledge that "working copy" and "repository" are very precise terms, I can (and do) see where confusion can come from.