Ben
Thanks very much - this is going to save lots of work. I got into this state
by wanting to checkout bits of a very large repository by using the external
meta property to pick out the bits that I want to work on at home.
I defined a new folder called /workspace and using "external" property I
defined just the bits I want to work on at home.
eg Repository contains /A & /B /C /D /E /F /G ...
Checking out just /A /B /C to work on at home works fine, but if update it
wants to pull down /D thru /Z, so I have to update/commit them individually.
So I created a workspace folder:
/Workspace/A which is an external defs to /A
similarly for /B & /C
I can commit & update /Workspace in one command which is much less
errorprone (there are really about 10 folder in the workspace)
This worked fine from home but then when I committed the changes it of
course it updated the meta properties for /workspace, so that when I updated
at work it created the new /Workspace folder (and this is the messy bit)
proceeded to duplicate /A into /workspace/A and /B into /workspace/B....
This is of course what it should do :-(
This is where I came unstuck: I had to give /A and /workspace a different
parent, so I created /Trunk and (using TortoiseSVNs repo browser) moved /A
into /Trunk/A /B into /Trunk/B ...
So now the top level is just:
/Trunk (containing the real /A /B /C /D ....
/Workspace (containg just external defs for /A /B )
Having moved all the previously top level items into Trunk, I made the
mistake of using the relocate rather than the switch command to retarget the
working copies. As I have hundreds of megabyte that have been moved, I'm
really glad to find out how to reconnect everything! Thanks.
SUGGESTION:
I'm using SVN to put a very large part of my workspace (~1.6GB) under
version control, primarily so I can work in different locations (as inspired
by the Linux Journal article on /home under CVS). It's working quite well
but there are large directories that don't change much (eg 400MB of PDFs and
1GB of images) and it would be very nice to be able to specify (for some
folders) NOT to CACHE a local copy of this data in .svn.
This would slow "reverts" but (from an non-developer's view) it would seem
that as they can't be used for DIFFs anyway and the timestamps would tell
you if files had been changed, this wouldn't really complicate things too
much (apart from an extra meta-property and commands to
"Checkout-NoLocalCopy". Copies could be fetched (as CVS does) when necessary
- effectively "Lazy evaluation".
The reason for keeping these big and mostly static directories under version
control is so that I can add/delete/move files in the workspace and SVN
makes sure that the other end(s) reflect the changes, and the "svnserver"
makes a dandy way of getting a remote file system.
Thoughts?
Thanks
Giovanni
>
> > **** The next is really all on one line
> > D:\>svn move -m "Repo Move" svn://SVNServer/Research/Test
> > svn://SVNServer/Research/Trunk/Test
> >
> > Committed revision 47.
>
> Okay, so /Trunk/Test exists in r47, but not in r46.
>
> >
> > D:\>cd test
> >
> > D:\Test>svn switch --relocate svn://SVNServer/Research/Test
> > svn://SVNServer/Research/Trunk/Test
> >
>
> And this is where you've made the mistake. You're using the
> '--relocate' switch when you shouldn't be. The '--relocate'
> switch is
> *only* for changing the SVNROOT: in other words, the schema, the
> hostname, or parts of the path leading *up* to the repository. It
> dumbly rewrites your URLs under the assumption that your working copy
> still reflects the *same path* within the repository.
>
> But instead, you've blindly rewritten your URLs to point to a
> *different
> path* in the repository. This is wrong, wrong, wrong. If
> you want your
> working copy to reflect a new path within the repository, you
> must use
> ordinary 'svn switch URL'. This is equivalent to "updating"
> to the new
> location... not just rewriting URLs, but working revs at well.
>
>
> > D:\Test>svn update
> > svn: Invalid editor anchoring; at least one of the input paths
> > is not a directory and there was no source entry
>
> And the reason you get this error...
>
> >
> > D:\Test>
> > ============================================================
> > ======== Contents of .svn/entries ==========================
> > ============================================================
> > <?xml version="1.0" encoding="utf-8"?>
> > <wc-entries
> > xmlns="svn:">
> > <entry
> > committed-rev="46"
> > name=""
> > committed-date="2004-05-13T10:54:17.792750Z"
> > url="svn://SVNServer/Research/Trunk/Test"
>
> ...is because your working copy claims to be a reflection of
> /Trunk/Test@46. But that location doesn't exist.
>
> If you had run 'svn switch URL' and not used the --relocate
> switch, your
> entries file would claim to be at /Trunk/Test@47, which *does* exist.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 13 15:43:57 2004