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

[Martin Pool]

On 11 Aug 2006, Robert Collins <robertc at robertcollins.net> 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'm certainly in favour of removing that.

> 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.

That sounds OK.  

I think the existing APIs are a bit low-level for what most callers will
want.  (For example plugins or other callers probably rarely want to
set the last revision, but rather to update the tree to a particular
revision.)  So having a single lower-level api that sets the parent list
and is cleaner would make sense.  I would want there to be clean
higher-level apis, along the lines of .merge() you just proposed.

> 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.

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.

-- 
Martin