Re: [Fwd: Re: incorrect result of merge]

Peter McNab <mcnab_p@melbpc.org.au> writes:
> While everyone is anticipating a new release shortly the following
> appeared on the TortoiseSVN dev list and hasn't yet made it over here
> yet.
> I thought it better to pass on earlier rather than later and sincerely
> hope it's not going to upset the originators

Has anyone reproduced this with stock Subversion? There's nothing
Tortoise-specific about the recipe. However, frustratingly the
transcript is not a true transcript, but rather an approximation of a
reproduction recipe, and at some steps I can think of multiple
different interpretations. A true script would be nice (hint, hint
:-) ).

I'm not trying to say "talk to the hand" at all, by the way. It's
just that I could spend hours trying to match the exact recipe in a
script, when someone who knows could get it right in ten or twenty
minutes...

Thanks,
-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
> -------- Original Message --------
> Subject: 	Re: incorrect result of merge
> Date: 	Thu, 15 Dec 2005 09:40:21 +0000
> From: 	Simon Large <simon@skirridsystems.co.uk>
> Reply-To: 	users@tortoisesvn.tigris.org
> Organization: 	Skirrid Systems
> To: 	users@tortoisesvn.tigris.org
> References:
> <274A369893F5FB4099345F006439D98705277403@bella.corp.resmed.org>
> 
> 
> 
> Michael Colefax wrote:
> > I noticed that one of our merges seems to have confused our repository.  On
> > a branch a file was moved.  Following the merge to the main trunk, it
> > re-appeared also in its original location.  However the log of the main
> > trunk doesn't show it ever being added there.
> > After some detective work, I have been able to reproduce the problem
> > in a
> > test repository.
> > I'm not sure if the problem is due to user error or due to a bug -
> > there was
> > a slight twist in the way the merge was performed: The entire branch wasn't
> > merged.  The bottom portion was merged first, and then the top portion -
> > skipping one of the middle revisions.
> > Here is the description of the scenario (using Tortoise 1.2.3 build
> > 4719):
> >   1. create a branch and switch to it (repository revision 3)
> >   2. create a folder, add a file in the folder, and commit to the branch
> > (rev 4)
> >   3. create another file, not in the folder, and commit to the branch (rev
> > 5)
> >   4. move the file created in step(2) to the parent directory, and commit to
> > the branch (rev 6)
> >   5. switch to the main trunk
> >   6. merge in the changes made on the branch in revision 4
> >   7. merge in the changes made on the branch in revision 6
> >   8. commit the merges to the main trunk
> > Following these steps, checkout the main branch.
> -------------------------------------------^^^^^^^
> You mean trunk
> 
> > The file created in step(2) appears in 2 locations!
> 
> I can reproduce this in r5039. Interestingly, running update on the
> original trunk does not generate the duplicate, only a fresh
> checkout. That's bad :-(  You should report this on the subversion dev
> list. It may be a known bug, but I find the SVN issue tracker very
> hard to search (I either get no results at all, or hundreds). Having
> said that, if they do  know I would have expected it to be serious
> enough to fix between 1.2 and 1.3 so maybe it is a new bug.
> 
> > During step(7) Tortoise indicated that the file was deleted from the folder
> > (as expected).  However when I repeated the same scenario but using
> > Subversion v1.2.3 r15833, Subversion indicated the deletion of the file was
> > skipped.  (In fact in step(8), Subversion incorrectly adds the file to the
> > main trunk, and does not indicate this in the change log...) The
> > issue for Tortoise is the difference in the reporting of the results
> > in
> > step(7).  Why does Tortoise indicate the file was deleted, while Subversion
> > indicate the deletion was skipped?
> 
> Hard to know what it should report. Evidently Subversion is broken
> here, but I suppose we should report the same as the CLI.
> 
> > The rest of the problems shown by this scenario lie with Subversion, and
> > thus are not discussed here.
> 
> Go tell 'em!
> 
> Simon
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
-- 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org