[RFC] Separating last-revision from parents

[John Arbash Meinel]

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

Aaron Bentley wrote:
> Aaron Bentley wrote:
>>> Robert Collins wrote:
>>>
>>>>> The current behaviour of update and revert is in my mind 'correct' -
>>>>> that is, we can probably improve it, buts its doing what I intended.
>>>>>
>>>>> I wanted the following to hold true for any tree:
>>>>> 'bzr update && bzr revert && bzr info -> no missing revisions, no local
>>>>> edits, no new local commits. 
> 
>>> I'm not sure why you want bzr update && revert to throw away local
>>> commits.  Perhaps you could elaborate on that.  But it sounds like
>>> perhaps it could be achieved more conveniently with a flag to update,
>>> anyhow.
> 
> Ping?
> 
> Also, see Erik Bågfors' suggestion for merge --reverse, which I believe
> would also work much better with a separation of last-revision and parents.
> 
> Aaron

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.

I do understand the problem with local commits disappearing after you
revert. But I never use 'commit --local'. My branch is either bound and
I'm working in lock-step, or it is unbound and I know that I'm working
with merge & push.

So I'm probably -0. I think it is added complexity, but if it can be
justified, I certainly wouldn't block it.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF0gGlJdeBCYSNAAMRAt59AKChYwYNn6boDPHLwviiDoSbVCY/sQCfQzWN
P7UcqYHe8TZnyV1cjTiS51A=
=eOEu
-----END PGP SIGNATURE-----