Comment 10 for bug 956268

Alex Lewis пишет:
> Ok here's the steps to reproduce a setup which caused my confusion...

I can reproduce it with command-line instead of explorer:

C:\Temp\4>bzr init trunk
Created a standalone tree (format: 1.14)
C:\Temp\4\trunk>echo > foo.txt
C:\Temp\4\trunk>echo > bar.txt
C:\Temp\4\trunk>bzr add
adding bar.txt
adding foo.txt
C:\Temp\4\trunk>bzr ci -m Initial
Committing to: C:/Temp/4/trunk/
added bar.txt
added foo.txt
Committed revision 1.
C:\Temp\4>bzr branch trunk feature
Branched 1 revision.
C:\Temp\4\feature>echo >> foo.txt
C:\Temp\4\feature>bzr st
modified:
   foo.txt
C:\Temp\4\feature>bzr ci -m Modify
Committing to: C:/Temp/4/feature/
modified foo.txt
Committed revision 2.
C:\Temp\4\trunk>bzr rm bar.txt
deleted bar.txt
C:\Temp\4\trunk>bzr ci -m Remove
Committing to: C:/Temp/4/trunk/
deleted bar.txt
Committed revision 2.

C:\Temp\4\feature>bzr st -r branch:../trunk
added:
   bar.txt
modified:
   foo.txt

But if we do

C:\Temp\4\feature>bzr st -rancestor::parent..-1
modified:
   foo.txt

Obviously bzr-explorer uses the first variant of getting status report,
but it should use the second one to get the correct result.

> So in my opinion the output in the bottom panel made me think that
> file1.txt would have reappeared in trunk when doing a merge (merging
> feature-x into trunk I mean). Bazaar actually behaved as I initially
> expected and just showed the change to file2.txt and did nothing with
> file1.txt.
>
> So is this a bug in Bazaar Explorer, just a different approach taken by
> Explorer compared to Bazaar or just my own confusion? Please feel free
> to pick the last option :)

It looks like there is bug in bzr-explorer regarding showing changes
against parent.

--
All the dude wanted was his rug back