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

RE: RE: Unexpected Merge Behavior

From: Daniel Becroft <Daniel.Becroft_at_supercorp.com.au>
Date: Fri, 5 Sep 2008 10:37:01 +1000

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_at_supercorp.com.au]
> Sent: Thursday, 4 September 2008 3:22 PM
> To: Ryan Schmidt
> Cc: users_at_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_at_ryandesign.com]
> > Sent: Thursday, 4 September 2008 3:05 PM
> > To: Daniel Becroft
> > Cc: users_at_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_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-05 02:36:44 CEST

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.