bzr bisect should update the working copy rather than revert it

I've actually thought about this too and done some coding. I'll look over my code and attach to the bug.

One thing I ran into was what to do with uncommitted changes. 'revert' would just throw them away while 'update' will try to move them away. Next update would move them again. Don't remember details now, but I ended up with lots of files being moved.

I think a good solution would be to refuse starting if there are uncommitted changes or even unknown files. That's also where I left when looking at this last time.

Please do not refuse to start if there are uncommitted changes. A reasonable use case is to bisect for a bug location, whilst maintaining some local change needed to facilitate the testing. Rather, bzr-bisect should just update the working tree, and halt bisection if conflicts occur during an update.

I have found that the current behavior (ala "bzr revert -r N") causes all sorts of conflicts in some cases which has made bzr-bisect unusable for me so far. Instead, I manually perform the bisection with a series of "bzr update -r N" commands.

> Please do not refuse to start if there are uncommitted changes.

That could be solved by refusing by default, providing a nice error message and accepting if bisect is started with a flag (such as —force) (e.g. "bisect has detected uncommitted changes in you working copy. These changes may conflict with the bisection process, it is recommended to shelve or revert them. If you want to bisect with your uncommitted changes applied, use the '—force' flag")

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/11/2011 10:36 AM, Xavier (Open ERP) wrote:
>> Please do not refuse to start if there are uncommitted changes.
>
> That could be solved by refusing by default, providing a nice error
> message and accepting if bisect is started with a flag (such as —force)
> (e.g. "bisect has detected uncommitted changes in you working copy.
> These changes may conflict with the bisection process, it is recommended
> to shelve or revert them. If you want to bisect with your uncommitted
> changes applied, use the '—force' flag")
>

If we used "update -r N" then it leaves uncommitted changes in the tree,
which isn't a very accurate model for "bisect". Since you aren't
actually testing the content of that revision.

I don't see why 'revert -r N' would cause more conflicts, maybe
something with non-empty directories? If so, update would have the same
conflicts, IIRC.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3KadgACgkQJdeBCYSNAAPTdACaAymwNXl3cwbLtc/O9Tu51RDZ
gGoAn3/7CDJly0fkQm5EAFvRawCq/YYp
=j6Sv
-----END PGP SIGNATURE-----

> If we used "update -r N" then it leaves uncommitted changes in the tree, which isn't a very accurate model for "bisect". Since you aren't actually testing the content of that revision.

No, but as Colin notes this is useful if you need some bit of code to test your bisection e.g. you implemented a new method (or a new test) which exposes breakage, you want to bisect with that code in place otherwise you have to reapply it every time (which becomes annoying fast).

> I don't see why 'revert -r N' would cause more conflicts, maybe something with non-empty directories?

1. Are you sure the conflict resolution is the same?

2. The issue is that `bzr revert` is a dirty working copy, knowing what was applied before and what bazaar brought back due to revert is much more painful than doing so with update.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/11/2011 1:08 PM, Xavier (Open ERP) wrote:
>> If we used "update -r N" then it leaves uncommitted changes in the
> tree, which isn't a very accurate model for "bisect". Since you aren't
> actually testing the content of that revision.
>
> No, but as Colin notes this is useful if you need some bit of code to
> test your bisection e.g. you implemented a new method (or a new test)
> which exposes breakage, you want to bisect with that code in place
> otherwise you have to reapply it every time (which becomes annoying
> fast).
>
>> I don't see why 'revert -r N' would cause more conflicts, maybe
> something with non-empty directories?
>
> 1. Are you sure the conflict resolution is the same?
>
> 2. The issue is that `bzr revert` is a dirty working copy, knowing what
> was applied before and what bazaar brought back due to revert is much
> more painful than doing so with update.
>

You can always do "bzr status -r N" and "bzr diff -r N", which should be
fairly obvious.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3KkZQACgkQJdeBCYSNAAPEPgCgkJXXTQ1JsFbVROm2uX2tdiR1
ADsAn1SMyeqM0gTEnxdsxVGq7ZyjbXr+
=gGfd
-----END PGP SIGNATURE-----

It also requires keeping track of the current revision under bisection, poses significant risks when trying to partially revert or shelve these modifications and is overall automatable grunt work, perfect for computers to perform.