[RFC] remove last-revision and pending-merge separation within the core code.

[Robert Collins]

Replying to many:

On Mon, 2006-08-14 at 08:28 -0500, John Arbash Meinel wrote:
> 
> I don't know that we want to prohibit it. But maybe. I know there are
> some use cases if you really want to start your revnos over. Instead
> of
> a 'bzr branch a b' you do 'bzr init; bzr commit; bzr merge; bzr
> commit'
> It might be nice if you didn't have to do that intermediate 'bzr
> commit'.
> 
> I'm not strong on supporting it, just an idea. 

Well, we can add that as a UI feature later by making the empty: tree an
explicit rather than implicit parent of new trees. Thats orthogonal to
the low level changes I want to make - and we would need to do something
to the history store to allow it to record a merge into an empty tree as
well.

On Mon, 2006-08-14 at 12:38 +1000, Martin Pool wrote:
> 
> As we discussed, I think having it turn into a pull is wrong, and I'd
> rather it just error.  I don't think it's such a major case that it
> needs to be specifically supported.  On the other hand it seems like
> we
> could, at some point in the future, allow for the 'origin tree'
> revision
> to be put into the list. 

I'm ok with it erroring. My question is - do you require that I add
explicit code to error, or is it ok to just have it degrade in the short
term ? I agree we can support the use case with the low level changes
I'm proposing in the future if desired.

-Rob






Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060815/3db8cd14/attachment.pgp