You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Daniel Becroft <Da...@supercorp.com.au> on 2008/09/04 01:58:14 UTC
Unexpected Merge Behavior
Hi all,
I have only recently started playing around with SVN's merge
capabilities, and have found something strange.
I have checked-out a fresh, unmodified copy of a branch in the
repository.
The structure is similar to this:
\alpha
\A
\B
\C.txt
\beta
...
\gamma
...
I am attempting to cherry-pick a single revision from trunk and apply it
to said working copy. The revision (r1234) only modifies a single file
(C.txt above), but when I run the following command:
svn merge -c 1234 svn://localhost/repo/trunk .
the svn process appears to be reading EVERY file in the working copy,
including those located under the \beta and \gamma directories. As a
result, the merge takes approximately 3 minutes to complete.
This performance does not sound so bad, but when using the 'multiple
revisions' option for the -C command, like so:
svn merge -C 1234,1236,1239,1255 svn://localhost/repo/trunk .
it takes approximate 3 minutes PER REVISION - it seems to do a loop
through the revisions and do the same thing for each.
Is this expected behavior for svn merge? Why is it reading completely
unrelated files when attempting a merge, rather than looking at the
changes being applied first?
Cheers,
Daniel B.
RE: RE: Unexpected Merge Behavior
Posted by Daniel Becroft <Da...@supercorp.com.au>.
I have read some more regarding the 'elliding feature' that you
mentioned.
However, I cannot determine why these unrelated directories are being
looked at at all.
Can anyone shed some light as to the reasoning behind it? Or should I
possibly be asking on the developer list?
> -----Original Message-----
> From: Daniel Becroft [mailto:Daniel.Becroft@supercorp.com.au]
> Sent: Thursday, 4 September 2008 3:22 PM
> To: Ryan Schmidt
> Cc: users@subversion.tigris.org
> Subject: RE: Unexpected Merge Behavior
>
> Hi Ryan,
>
> Yes, I am using 1.5.1 (have tried under 1.5.2 and there is no
> difference) under WinXP.
>
> I'm still confused as to why SVN is looking at files under
> directories \beta and \gamma, when the only file being
> modified is under \alpha.
> After the merge, neither \beta or \gamma have been modified
> in any way - shouldn't these be getting ignored completely?
>
> Cheers,
> Daniel B.
>
> > -----Original Message-----
> > From: Ryan Schmidt [mailto:subversion-2008c@ryandesign.com]
> > Sent: Thursday, 4 September 2008 3:05 PM
> > To: Daniel Becroft
> > Cc: users@subversion.tigris.org
> > Subject: Re: Unexpected Merge Behavior
> >
> >
> > On Sep 3, 2008, at 8:58 PM, Daniel Becroft wrote:
> >
> > > I have only recently started playing around with SVN's merge
> > > capabilities, and have found something strange.
> > >
> > > I have checked-out a fresh, unmodified copy of a branch in the
> > > repository.
> > >
> > > The structure is similar to this:
> > >
> > > \alpha
> > > \A
> > > \B
> > > \C.txt
> > > \beta
> > > ...
> > > \gamma
> > > ...
> > >
> > > I am attempting to cherry-pick a single revision from trunk
> > and apply
> > > it to said working copy. The revision (r1234) only modifies
> > a single
> > > file (C.txt above), but when I run the following command:
> > >
> > > svn merge -c 1234 svn://localhost/repo/trunk .
> > >
> > > the svn process appears to be reading EVERY file in the
> > working copy,
> > > including those located under the \beta and \gamma
> > directories. As a
> > > result, the merge takes approximately 3 minutes to complete.
> > >
> > > This performance does not sound so bad, but when using the
> > 'multiple
> > > revisions' option for the -C command, like so:
> > >
> > > svn merge -C 1234,1236,1239,1255 svn://localhost/repo/trunk .
> > >
> > > it takes approximate 3 minutes PER REVISION - it seems to
> do a loop
> > > through the revisions and do the same thing for each.
> > >
> > > Is this expected behavior for svn merge? Why is it reading
> > completely
> > > unrelated files when attempting a merge, rather than
> looking at the
> > > changes being applied first?
> >
> > Are you using Subversion >= 1.5? If so, maybe this is the mergeinfo
> > eliding feature at work.
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Unexpected Merge Behavior
Posted by Daniel Becroft <Da...@supercorp.com.au>.
Hi Ryan,
Yes, I am using 1.5.1 (have tried under 1.5.2 and there is no
difference) under WinXP.
I'm still confused as to why SVN is looking at files under directories
\beta and \gamma, when the only file being modified is under \alpha.
After the merge, neither \beta or \gamma have been modified in any way -
shouldn't these be getting ignored completely?
Cheers,
Daniel B.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2008c@ryandesign.com]
> Sent: Thursday, 4 September 2008 3:05 PM
> To: Daniel Becroft
> Cc: users@subversion.tigris.org
> Subject: Re: Unexpected Merge Behavior
>
>
> On Sep 3, 2008, at 8:58 PM, Daniel Becroft wrote:
>
> > I have only recently started playing around with SVN's merge
> > capabilities, and have found something strange.
> >
> > I have checked-out a fresh, unmodified copy of a branch in the
> > repository.
> >
> > The structure is similar to this:
> >
> > \alpha
> > \A
> > \B
> > \C.txt
> > \beta
> > ...
> > \gamma
> > ...
> >
> > I am attempting to cherry-pick a single revision from trunk
> and apply
> > it to said working copy. The revision (r1234) only modifies
> a single
> > file (C.txt above), but when I run the following command:
> >
> > svn merge -c 1234 svn://localhost/repo/trunk .
> >
> > the svn process appears to be reading EVERY file in the
> working copy,
> > including those located under the \beta and \gamma
> directories. As a
> > result, the merge takes approximately 3 minutes to complete.
> >
> > This performance does not sound so bad, but when using the
> 'multiple
> > revisions' option for the -C command, like so:
> >
> > svn merge -C 1234,1236,1239,1255 svn://localhost/repo/trunk .
> >
> > it takes approximate 3 minutes PER REVISION - it seems to do a loop
> > through the revisions and do the same thing for each.
> >
> > Is this expected behavior for svn merge? Why is it reading
> completely
> > unrelated files when attempting a merge, rather than looking at the
> > changes being applied first?
>
> Are you using Subversion >= 1.5? If so, maybe this is the
> mergeinfo eliding feature at work.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unexpected Merge Behavior
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 3, 2008, at 8:58 PM, Daniel Becroft wrote:
> I have only recently started playing around with SVN's merge
> capabilities, and have found something strange.
>
> I have checked-out a fresh, unmodified copy of a branch in the
> repository.
>
> The structure is similar to this:
>
> \alpha
> \A
> \B
> \C.txt
> \beta
> ...
> \gamma
> ...
>
> I am attempting to cherry-pick a single revision from trunk and
> apply it to said working copy. The revision (r1234) only modifies a
> single file (C.txt above), but when I run the following command:
>
> svn merge -c 1234 svn://localhost/repo/trunk .
>
> the svn process appears to be reading EVERY file in the working
> copy, including those located under the \beta and \gamma
> directories. As a result, the merge takes approximately 3 minutes
> to complete.
>
> This performance does not sound so bad, but when using the
> 'multiple revisions' option for the -C command, like so:
>
> svn merge -C 1234,1236,1239,1255 svn://localhost/repo/trunk .
>
> it takes approximate 3 minutes PER REVISION - it seems to do a loop
> through the revisions and do the same thing for each.
>
> Is this expected behavior for svn merge? Why is it reading
> completely unrelated files when attempting a merge, rather than
> looking at the changes being applied first?
Are you using Subversion >= 1.5? If so, maybe this is the mergeinfo
eliding feature at work.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org