[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Thoughts about Modules (request for comments)
From: |
Graydon Hoare |
Subject: |
[Monotone-devel] Re: Thoughts about Modules (request for comments) |
Date: |
Mon, 06 Aug 2007 23:30:03 -0700 |
User-agent: |
Thunderbird 2.0.0.6 (Windows/20070728) |
Bruce Stephens wrote:
Right, so this is the same idea as nested checkouts, but using the
manifest rather than some other mechanism?
We've batted around the shape and texture of this for years, but nobody
ever pushed on it hard enough to implement. It's one of those "broad yet
shallow" UI shifts that takes a lot of work to accomplish what seems
like not-a-huge-feature. Even though everyone likes it, or something
*like* it. Would have been easier if we'd designed it into the first
pass, but we drew the line of what to implement a bit short of that
(indeed, even restrictions were a bolt-on, with similarly broad strokes
touching the entire UI).
Isn't it cleaner to use attributes, as suggested in
<http://www.venge.net/mtn-wiki/AttrUseCases> (and probably elsewhere)?
Yeah, I think we already have sufficient machinery for this. Just
reserve an attr name on a dir. No need to revisit the manifest / roster
format.
My $0.02: I think it is important to consider this in terms of contrast
with pivoting roots. If you have a 3rd party library / module that you
want to have tightly integrated / recursive / shared history with the
containing project, you can just use pivoted roots. Then the containee
history moves in lock-step as "part of" the container history.
This is specifically about cases where you want *looser* coupling
between container and containee than you get with pivoting roots. In
particular:
- To keep the containing project's roster size down
- To keep the containing project's history uncluttered with all the
details of the evolution of the contained projects
- To make a simple / obvious scheme for *reusing* contained projects
between multiple containing projects without having to pivot each
use in separately.
- (possible) To make a way of persistently noting external non-monotone
sources for automatic / scripted re-importing. Less ad-hockery.
I think these will only come up in large aggregating projects such as
distros, but they're still important enough to cater to a bit. The
tricky part is this:
- if you only store a "symbolic link" to the containee, you have to
make sure the containee history graph (and content!) moves along with
the container history graph when you netsync. You don't want to get a
project that cannot be fully checked out!
You could accomplish all but the first goal by using a sort of "history
restriction" that collapsed or summarized changes that were confined to
a marked directory. But you'd still have huge rosters. To get the small
rosters, you need to store symbolic links of some sort.
It is possible that git split the abstraction better here, and hashing
directory nodes recursively would have worked better. I am unsure: they
also chose not to manage persistent node identifiers that are stable
across inter-directory moves. That might get ugly (or require dropping
down to some sort of GUID) if you want to be able to share content
subtrees between different container histories.
-graydon
- [Monotone-devel] Re: Thoughts about Modules (request for comments),
Graydon Hoare <=