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

John Arbash Meinel john at arbash-meinel.com
Mon Aug 14 14:28:34 BST 2006


Robert Collins wrote:
> I've finished analysing merge/pull/update/commit's use of
> revision-trees.
> 
> We do a lot of double handling, and it will be easiest IMO to remove
> this by having the parents of workingtree a single list, rather than a
> nullable last-revision and a list.
> 
> For instance, merge builds a revision tree during merge. We then build a
> new revision tree from the repository during commit to calculate per
> file merge history. Commit then makes a new revision tree from the
> repository of the inventory it just committed, which is passed to the
> tree as the last revision. Thats two unnecessary trips to the repository
> - which costs.
> 
> I'll write up a spec about how I think the cleanest API can look like -
> but I'd like to get broad agreement on the basic change which is:
> 
>  * remove set_last_revision
>  * remove add_pending_merge
>  * probably remove pending_merges() and last_revision()
> 
> And replace them with apis that just work on manipulating a parents
> list.

At one point, we had talked about changing from passing around string
'revision_id' parameters, into a lazily evaluated RevisionTree object.

That may be relevant here.

> 
> Semantic calls on that will take care of removing duplicate parents,
> removing parents which are in the ancestry of another etc.
> 
> This will change one key thing - it will no longer be possible to have a
> last-revision of None and a pending merge - the first parent added will
> become the last-revision.
> 
> This means that 'init' && 'merge other' will effectively degrade to
> 'init && pull other'. We could prohibit 'merge into a tree with no
> history' to avoid confusion in this case.
> 
> Your thoughts?
> 
> Rob 

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.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060814/8c97400b/attachment.pgp 


More information about the bazaar mailing list