Ideas/Subrepositories
What are subrepositories?
What should using subrepositories be like?
It should…
- retain darcs’ simplicity
- allow the user to do operation once - i.e. one record for all subrepositories
- prevent subrepository boundaries from being crossed
- (fancy?) make it possible to share subrepositories across different parent repos
- Andrew’s wish: track subrepository patches with the umbrella repository, but allow for selectively pulling patches from the subproject’s original repository into this one, as well as pushing them back out. (say, I wanted my own branch of project B as part of my project A, and wanted to keep B updated by pulling patches into it from the outside, and pushing my own patches to B back out to the community, all the while keeping my own version of B as just a part of project A, with patches to A and B all together.
How could do we accomplish this?
List of proposals
- Explicit support for NestedRepositories via special patch types
- Domains
NestedRepo patch types
http://lists.osuosl.org/pipermail/darcs-users/2005-October/008450.html
Summary
Details
(JuliuszChroboczek and DavidRoundy)
Examples
Domains (John Meacham)
Summary
Details
Examples
Subrepos a la git submodules (Ben)
Summary
In git, a submodule is represented as an object in a tree that is neither a file (blob) nor a tree but a commit from another repository. The idea is that we track changes to a subrepo in the parent repo but only at the coarser level of commits, not files and directories.
The natural home for an equivalent feature in Darcs is the FileUUID primitive patch type. Objects aquire a third constructor for subrepos (in addition to the ones for files and directories), so a subrepo, if manifest, has a location (a name in some directory). The data associated with a subrepo (i.e. the information we track about it in the parent repo) is the set of abstract patch identifiers i.e. the hash you see in ‘darcs log’. Patches that modify this state contain a set of patches to remove and a set of patches to add, similar to hunks.
A different idea is to use a combination of inventory and pristine hash to signify the state of the subrepo. The same pros and cons as for ShortSecureId apply: the inventory hash is fast and secure, but not invariant under commutation; subrepo modifying patches would never commute with each other, similar to (V1) binary patches.