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.
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 4\trunk> echo > foo.txt 4\trunk> echo > bar.txt 4\feature> echo >> foo.txt 4\feature> bzr st 4\feature> bzr ci -m Modify
Created a standalone tree (format: 1.14)
C:\Temp\
C:\Temp\
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\
C:\Temp\
modified:
foo.txt
C:\Temp\
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