2

Recently I've been experimenting with svn:externals and started having an error message when I perform SVN Update.

Z:\Projects\workB\trunk

Cannot relocate 'Z:\Projects\workB\trunk' as it is not the root of a working

copy; try relocating 'Z:\Projects\workB' instead

enter image description here

As this page suggests, I performed TortoiseSVN → Relocate on Z:\Projects\workB via the context menu. Then I get this message box.

It seems you are trying to relocate your working copy to a different path inside the same repository.

From: file:///Z:/repos/repoB

To: file:///Z:/repos/repoB

enter image description here

Is this normal? The both, From: and To: paths are the same although the warning message says a different path. I'm wondering if it's okay to press YES here.

This might be related: Problem trying to relocate WC to new repository

[Update]

To explain what I've done to cause the first error (Cannot relocate etc.), the current directory structure is like this.

Z:\repos\repoA

Z:\repos\repoB

Z:\Projects\workB

Z:\Projects\workB is a checkout of the repository repoB. And I created a svn:externals on Z:\Projects\workB with the following steps. ( I tried to import the whole trunk folder and its contents from repoA to Z:\Projects\workB\trunk. There is a reason I wanted to do this but it's going to be a long story. )

  1. Right clicked on Z:\Projects\workB and selected TortoiseSVN -> Properties

  2. New -> Externals

  3. Pressed New...

  4. Typed "trunk" for Local path and "file:///Z:/repos/repoA/trunk" for URL and closed the setting windows.

    enter image description here

  5. Right clicked on Z:\Projects\workB and selected SVN Commit... and pressed OK to apply the externals definition. The commit went through.

  6. To see if the external files get imported, I right clicked on Z:\Projects\workB and selected SVN Update

And I got the first error that says try relocating.

Community
  • 1
  • 1
Teno
  • 2,582
  • 4
  • 35
  • 57
  • So, *are* your `From:` and `To:` paths the same? Then there is no need to press "Yes". – AndreKR Oct 15 '12 at 18:37
  • @AndreKR `So, are your From: and To: paths the same?` - Yes. As the picture I attached to the question indicates they are both `file:///Z:/repos/repoB` `Then there is no need to press "Yes"` - Oh really. Thanks for the answer. In that case, the error message becomes mystery though. It says "try relocating". And I actually pressed Yes to see what happens and got a message `Working copy relocated to file:///Z:/repos/repoB`. Do you think this whole warning and error messages I got is normal? I'm wondering if I've done something wrong. – Teno Oct 15 '12 at 18:59
  • Oh, sorry, I did not see that this happens during *updating*. I thought: why would you want to relocate when you don't want to relocate. So the real error is the first one. Maybe you should point that out. – AndreKR Oct 15 '12 at 19:09
  • @AndreKR `So the real error is the first one. Maybe you should point that out.` - I see. Should I close this question and start a new topic or edit and add an additional info which tells what I've done to cause that error? – Teno Oct 15 '12 at 19:20
  • Just edit your question, espacially as no one has responded yet. Make it clear that it happens on update, give more information on the (possible) cause and remove the second part - "trying relocating" is obviously not going to solve that problem. :) – AndreKR Oct 15 '12 at 19:31
  • @AndreKR I updated the question. I hope it is clear what I've done. – Teno Oct 15 '12 at 20:08
  • 3
    By any chance... Do you happen to have a `file:///Z:/repos/repoB/trunk`? If so, you're attempting to checkout repoA into trunk where trunk is already a directory in repoB. – David W. Oct 16 '12 at 00:48
  • @DavidW. `Do you happen to have a file:///Z:/repos/repoB/trunk?` - Ops. This was it. I had the exact same mistake before. Thanks for pointing it out, I thought it was only enough to delete `Z:\Projects\workB\trunk`, which is in the checkout directory. – Teno Oct 16 '12 at 04:47

1 Answers1

4

No, no, no!

Don't ever, ever use the file:/// URL -- especially with shared projects. It's bad, it's terrible, it's not a very good idea.

If nothing else, use the svnserve process to start up a Subversion server. It's fairly simple, and no one will have direct access to your Subversion repository directory.

The file:// URL is good when playing around with Subversion, but should never be used with an actual project. Take a look at Subversion Edge by CollabNet if you want an open source Subversion server. This will allow you to serve your repository over http:// on a Windows server. Another popular one is VisualSVN Server. It's not open source, but a lot of people like the free version for setting up Subversion repositories.

You didn't give too much information. Do you realize in Subversion that you checkout the files you want to work on in a working directory? For example:

 C:> cd C:\workdir
 C:> svn co file:///Z:/Projects/workB/trunk workB-trunk

That will create a local copy on C:\workdir\workB-trunk. This is where you can play around with your files. note how your repository is in a different location than the files you checkout. I have a feeling that's why you're seeing the relocate stuff.

To use svn:externals, you'd put the svn:externals property on the directory of your project:

 C> cd \workdir\workB-trunk
 C> svn propset svn:externals "^/Z:/Projects/WorkC/trunk workC" .
 C> svn update

This will place the most recent version of file:///Z:/Projects/WorkC/trunk inside your working copy of workB-trunk. Commit the change, and everyone will get this when they checkout file://Z:/Projects/WorkC/trunk.

Solution

By any chance... Do you happen to have a file:///Z:/repos/repoB/trunk? If so, you're attempting to checkout repoA into trunk where trunk is already a directory in repoB.

In that case, simply delete file:///Z:/repos/repoB/trunk.

Teno
  • 2,582
  • 4
  • 35
  • 57
David W.
  • 105,218
  • 39
  • 216
  • 337
  • 1
    I think it's totally legitimate to use file access to check out a local repository to keep a version history of files you edit. Why does this break the update? – AndreKR Oct 15 '12 at 19:54
  • 1
    @David_W. Thanks for the detailed answer and useful information about the SVN server programs. I used the `file://` protocol to play around with Subversion. I've just started using Subversion and trying to learn how to use it. I updated the question to explain how the error occurred. – Teno Oct 15 '12 at 20:06
  • 1
    @AndreKR If you are the only one using the repository, the `file://` isn't dangerous. HOWEVER, if you are sharing the repository, you should never use `file://`. In order to use `file:///`, the repository itself is read/writeable by everyone. Everyone has total control which means that I could make changes directly to the repo directory. The repo is on a shared drive using the `file:///` protocol. Instead, they should use `svnserve` or use `httpd` by using one of the free Apache/SVN integrations for Windows. – David W. Oct 16 '12 at 00:22
  • I still don't get how this answer is related to the problem. It seems the real answer is your comment on the question. – AndreKR Oct 16 '12 at 07:43
  • 1
    @AndreKR I agree. I accepted it as the answer since my problem got solved but it may confuse future users. So I suggested an edit. – Teno Oct 16 '12 at 09:01
  • "No, no, no!" - you sound like a whiny baby. :) Your opinion on the scheme to use to access a repository does nothing to answer the OP's question! – Josh M. Feb 21 '14 at 12:40
  • @JoshM. This is a warning to the OP that they were doing a very bad practice. The repo has no protection because it's being accessed directly and shared. It's like someone asking me how to load a flintlock rifle, and I notice they're storing the gunpowder next to their furnace. I'll answer the question, but warn the user of the bad practice. By the way, this is not merely my _opinion_. Check out the Subversion manual, and you'll see the same warning. See the bottom of [this page](http://svnbook.red-bean.com/en/1.7/svn.serverconfig.choosing.html). – David W. Feb 21 '14 at 16:25
  • Sure, it's absolutely the wrong way to really use SVN - but the OP was just learning SVN locally so I didn't see any harm there. Doesn't really matter anyway, I suppose. – Josh M. Feb 21 '14 at 20:16