What I've learned from scmproj (Re: what should be done to merge nested trees patch to bzr-core?)

[John Arbash Meinel]

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


...

> e) Uncommit -- very hard thing to do it properly. You don't want it to
> be blindly recursive, but you'd better have it recursive and uncommit
> what have been committed. So, if you committed root and component A, but
> component B is not changed, then on uncommit of root you also want to
> uncommit A, but not B for obvious reasons. The reverse is also true: on
> uncommit in A you also will want to uncommit in root, because it will
> have recorded revision-id of uncommitted revision in component A.

I don't think you need to uncommit in root. It just happens that the
subdirectory is rolled back to an earlier version, which should be
allowed, if not recommended. It does make *fetch* a bit trickier,
because now the most recent tip of a subdir is not necessarily the most
recent in the DAG. However an appropriate fetch should still handle it
just fine. (When updating the outer project, it should see what
(tree_id, revision_id) pairs have been seen, and fetch all of those
revisions into the local repository.)



> 
> The things will faster becomes too tricky to handle if you want uncommit
> B. In this case you may want to uncommit root too, down to the point
> when revision of B has been recorded. And it may trigger uncommits in
> other components to the same level. It will be too destructive, IMO. But
> otherwise you'll have inconsistent tree, in any case. I think uncommit
> itself should be prohibited in nested trees, just because it might
> destroy too much. Where you will find uncommitted revision pointed to by
> project root in general? That's very very tricky.

As I said, if you avoid uncommit propagating upwards, this isn't a problem.

> 
> I don't have any answer on this problem. But I think that problem is
> somewhat similar to problem with tags pointing to revision outside the
> branch history.
> But if you can't use tag you won't loose too much. But if you're unable
> to checkout your past state of the project because there is no revision
> stored in snapshot, what will you do? That's complete inrecoverable
> failure.
> 
> Currently when I need to uncommit something in the project locally, I
> should tread very very carefully. And I think in general case it's much
> better to just make a reverse merge.

Often it is better to do reverse merges anyway. But for other reasons.

...

> 2) Composite history.
> 
> Currently I don't see (or don't understand) how can you get the
> composite log for the entire project. I can imagine that history of
> components could be shown as virtual merge points when root component
> has recorded revision ids of nested components. That will be really
> good, but I'm not sure about performance of such approach. Maybe it will
> be good enough to be usable.
> 
> In general I'd like to have recursive qlog by default.
> 
> But beware of uncommits and `pull --overwrite` -- they may destroy the
> history and therefore you won't be able to see composite log.
> 

I do think this is something worth thinking about. I would probably do
it with some form of nesting. So at the top level you can see the root
graph with its commits and merges, etc. At any given node, if there are
subtree commits, you can click an expander to see the graph for that
subtree. I'm not sure how it should look for a revision which *removes*
history (uncommit in a subproject, commit in the parent). But you could
probably visualize it with nodes that have strike-through to indicate
that these were removed in the given commit.


...

> But as I think further, I come to conclusion that the best nested trees
> can be obtained if we just merge components into root component. This
> will automatically solve a lot of highlighted problems. But it will
> create a new problem: how to extract the component then? Share changes
> between projects using the same component?

I believe Aaron was working towards a "logical merge" (CompositeTree
looks like one giant WorkingTree). The main failure of it was stuff like
file-ids must be unique across the tree (so you can't nest the same
library 2 times at different locations, etc.)

> 
> I have some ideas about that, but as I can see they cannot be
> implemented within bzr model.
> 
> I hope my story will be useful.
> 

I certainly think having real experience in this area is useful, and
will help guide us to a solution that is useful for you.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk357VcACgkQJdeBCYSNAAN9DACdFgV9qD+vvY8S5dLVp5r/VKq+
nMAAoKVfdCSp65tMDHf3NsGRBumlDhar
=RRDZ
-----END PGP SIGNATURE-----