Ben Collins-Sussman wrote:
> 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.
I believe it is a bug then, but judge yourself. I used the following little
script to reproduce the error. The last merge in fact does something while it
# name of a project
# temp repository
svnadmin create test
# export some version of a project from another repo
svn export -r50 $OTHERREPO/$PROJECT
# import into temp repo and remove unused export dir
svn import $PROJECT $TMPREPO/$PROJECT -m "imported"
rm -rf $PROJECT
# create workingcopy from
svn co $TMPREPO/$PROJECT
svn merge -r50:100 $OTHERREPO/$PROJECT $PROJECT
> > 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).
I've been achieving sufficiently much of what I needed to do with
svn_load_dirs now, the only ugly thing being that I can't specify a comment
and thus had to enable editing the svn:log property lateron.
> > 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.
I don't know the ways SVN works well enough to tell, but isn't this an
unnecessary restriction? I'd appreciate getting a warning or even having to
use --force, but this...!?
> 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.)
AOL. An enhanced diff format would exactly be the tool to solve my problems.
thanks for you input
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon May 2 17:37:46 2005