want option to allow uncommit but disallow changing mainline

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

Loïc Minier wrote:
> Public bug reported:
>
> Binary package hint: bzr
>
> Hey
>
> I think we need a way to prevent bzr push from replacing the history
> when it think it can do so; this might not be the right thing to do for
> local branches, but it's certainly the default behavior we want in
> Launchpad.
>
> Here's the story
>
> 16:43 < lool> poolie: So basically someone had a bzr branch of our trunk, did a
> local commit, pushed to a topic branch in launchpad, asked for a
> merge
> 16:43 < lool> I merged it, pushed to the trunk branch
> 16:44 < lool> this guy then did another merge, forgetting that he abused his
> local trunk branch as a topic branch
> 16:44 < lool> he pushed
> 16:44 < lool> Launchpad accepted that silently
> 16:44 < lool> but sent out an email that one revision had been removed
> 16:44 < lool> I was told this bzr behavior makes sense when working locally
> 16:44 < lool> If you look at the history now though, it misses my merge
> completely

Isn't the original fix for this setting "append_revisions_only" on the
trunk? (Preventing this sort of behavior).

In the short term, doing:

 bzr branch lp:.../trunk -r -2
 bzr merge XXX
 bzr commit -m "Merging X correctly"
 bzr push --overwrite lp:.../trunk

There are other ways, but it seems reasonable.

John
=:->

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

iEYEARECAAYFAkw9fAQACgkQJdeBCYSNAAMiawCfcbsuF0YbEFWDgA7wgtgh7SR4
gaMAnRcNnGpm3HjuXCZcWv0cCtJuYWcT
=rzkq
-----END PGP SIGNATURE-----

On 14 July 2010 10:57, John A Meinel <email address hidden> wrote:
> Isn't the original fix for this setting "append_revisions_only" on the
> trunk? (Preventing this sort of behavior).

That would prohibit uncommits. Perhaps it is reasonable to want
explicit uncommits but not changing the mainline.

--
Martin

Exactly; we want to allow uncommits because these are explicit but disable the implicit default of replacing/overwriting history.

The main use case is Launchpad code hosting for me here, but I'm happy if that also covers other bzr workflows.

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

Martin Pool wrote:
> On 14 July 2010 10:57, John A Meinel <email address hidden> wrote:
>> Isn't the original fix for this setting "append_revisions_only" on the
>> trunk? (Preventing this sort of behavior).
>
> That would prohibit uncommits. Perhaps it is reasonable to want
> explicit uncommits but not changing the mainline.
>

It does, but if you prevent getting there in the first place, you might
be okay.

Uncommit is pretty dangerous on a trunk that people integrate around,
since suddenly a revision in the history disappears, and everyone has to
figure out how to resync.

Given the nature of it, is there a problem making it 2-phase?

1) Unset the append_revisions_only flag, indicating that for the next
bit it is okay to mutate history a bit.
2) Uncommit
3) set append_revisions_only back to True.

I think not having that automated is a reasonable tradeoff between being
possible, and shooting yourself in the foot by doing it accidentally.

However, we certainly need to make it easier to set (and unset) the
append_revisions_only flag.

John
=;->

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

iEYEARECAAYFAkw+urkACgkQJdeBCYSNAAOUIACeIW+/KcYrzUurM3GZGKYSV+OB
h/AAoLZV7Zj3IPlmlzAKzMX8uBz+Vzg+
=G0yA
-----END PGP SIGNATURE-----

We agree uncommit is dangerous, but it can't be triggered by accident; people will have to explicitly type uncommit. I have a problem when a regular "bzr push" in the default configuration can change history though.

If you propose that whenever I mean to "bzr uncommit" I have to "bzr disable-append-revision-only", "bzr uncommit", and "bzr reenable-append-revision-only", then I'm going to as for a "bzr really-uncommit" instead! :-)

@lool, I think John's point is that bzr really-uncommit should also send an email to all subscribers of the branch explaining how to resync their branch which is (finding the subscribers) not trivial.

You may also want to me-too bug #491196 that is aimed at addressing last John's remark about an easy way to set/unset the apprend_revisions_only flag.

Vincent, thanks for the pointer. I don't think the uncommit case might not always require a fix from subscribers. The rare cases where I uncommited were usually immediately after a push or commit, presumably letting only a short window of time for people to base of the uncommitted revision. But I guess it would be nice in some cases to indeed have this notification.