[RFC] Separating last-revision from parents
Aaron Bentley
aaron.bentley at utoronto.ca
Tue Feb 13 18:44:31 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Arbash Meinel wrote:
> Aaron Bentley wrote:
>
> I think this ends in a simple split between how you see checkouts and
> how Robert sees them. I haven't settled which one I believe in, yet.
>
> Specifically should "bzr update; bzr revert" leave you at the tip of the
> master branch, or should it put you back to where you were at before the
> 'bzr update'.
>
> I probably lean towards Robert, because that is what checkouts are *for*
> in my opinion. To declare another branch as more important than where
> I'm working at the moment.
This doesn't make any sense to me. Why would you update && revert to do
this? That's annoying, and not discoverable. Certainly, there should
be a way to achieve that. Maybe "update --lose-local" or another flag.
> I do understand the problem with local commits disappearing after you
> revert. But I never use 'commit --local'.
Well, this is specifically about supporting commit --local properly. If
we're not going to do that, then IMHO, we shouldn't support commit
- --local at all.
> So I'm probably -0. I think it is added complexity, but if it can be
> justified, I certainly wouldn't block it.
I agree that it adds complexity. When people wanted to add a
last_revision for working trees, I argued against it because of the
complexity it introduced. But everyone seemed to think the extra
complexity was worth it. Well, this is the consequence of that
decision, so I don't think complexity is a fair argument.
You seem to also be ignoring the other issue, which is the desire for
merge --reverse to swap the parents. This means that if you have a
feature branch, and the mainline has "append_revisions_only", you can
easily still merge, commit and push your work.
And there is also the point that you probably don't want tree comparison
operations (diff, status, commit) to reflect your local changes after
update or merge --reverse. You want them to reflect
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFF0gcP0F+nu1YWqI0RAl+ZAJ9fNjPrcLlsxUan/tQuZohOzT6yjQCeLcY+
0TzBAXjLFZTj3zMbGXubVaQ=
=7dvf
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list