[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merging a patch

From: Ulrich Eckhardt <eckhardt_at_satorlaser.com>
Date: 2005-05-02 17:36:41 CEST

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
shouldn't.

# name of a project
PROJECT=SwimStarBrowser
# temp repository
svnadmin create test
TMPREPO=file://$PWD/test
# export some version of a project from another repo
OTHERREPO=svn://image-server/software/trunk
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).
>
> Agreed.

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

Uli

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 2 17:37:46 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.