On Apr 29, 2005, at 9:22 AM, Ulrich Eckhardt wrote:
>
> 1. From inside a workingcopy, do 'svn merge -rX:Y svn://repos1/path .'
> or the
> equivalent using a URL. This yields 'Access schema mixtures not yet
> supported' from subversion, although it seems to patch at least one
> file. I
> believe that is a bug.
If it does anything at all, it's a bug. It should give you an error
about the working copy repository being different than the repository
URLs you're comparing.
> 2. Use good old unix pipes: 'svn diff -rX:Y svn://repos1/path|patch
> -p0'. This
> works, but newly created files are not added to subversion that way.
This is as close as it gets. As the grey box in the book discusses,
'patch' won't deal with adding/deleting directories either... or deal
with properties.
> 3. Using svn_load_dirs. The problem with this approach is that it is
> way too
> specialised for tracking external sources and that you can't specify a
> comment for the commit (if it turns out to be just one, which I'm sure
> it
> would be for my case).
Agreed.
> 4. svnadmin dump/load. This unfortunately requires direct repository
> access,
> which is why this is not an ideal solution for me. Other than that,
> this is
> almost the perfect match for my problem, I just need to copy a few
> revisions
> for one repository over to another.
Yep, not very convenient.
>
> An idea I got along the way was to use 'svn merge' by piping in a
> patch, like
> 'svn diff -rX:Y svn://repos1/path|svn merge - .' but that is not
> supported.
> Interesting addition?
Eek! 'svn diff' and 'svn merge' are doing the same network requests...
they're nearly identical code under the hood. They both ask the server
to compare two trees. So no, this isn't going to work.
>
> Another odd thing I noticed is that you can't merge anything in a
> non-working
> copy.
Correct, the help-text and documentation clearly state that 'svn merge'
takes a working copy target, not a bunch of unversioned files.
Have you tried svk? It sounds like it would solve your problem exactly.
This is also the reason why we'd like to have a subversion "patch
format" -- something which captures tree structure and properties. We
used to have such a thing in the very early days (it was an XML
format), but it's gone from HEAD now. It's not been reimplemented or
resurrected, because a lot of folks want any new patch format to be
backward-compatible with GNU patch (so that GNU patch ignores parts it
doesn't understand.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 2 16:50:38 2005