[darcs-users] Re: post-1.0: "isolated directories"?

Jamie Webb j at jmawebb.cjb.net
Fri Oct 15 17:07:14 UTC 2004


On Fri, Oct 15, 2004 at 07:10:54AM -0400, David Roundy wrote:
> I'm liking this idea more and more.

Mmm, I like it too. I'm concerned though about the possible
proliferation of dependency repos, e.g. suppose I have a library
libfoo and two applications bilbo and frodo which use it. At present,
I'd have something like:

repos/
	libfoo/
		head/
		1.0/
		1.1/
	bilbo/
		head/
		1.0/
	frodo/
		head/
		1.0/

And I'd have to manually ensure that a branch of libfoo exists
corresponding to the versions required by each branch of each
application. Using metarepos, AIUI, I could have:

repos/
	libfoo/
		head/
		1.0/
		1.1/
	bilbo/
		head/   (metarepo)
			libfoo/
			core/
		1.0/    (metarepo)
			libfoo/
			core/
	frodo/
		...

And each libfoo subrepo would contain exactly the version required by
that application branch, which is very neat. But, even with just 2
apps each with 2 branches, the number of libfoo repos has gone from 3
to 7, and many of them are likely to be identical. Aside from the disk
and bandwidth wastage, I'm wondering about the complexity in terms of
workflow of managing that many instances. And what if libfoo in turn
had dependencies? The whole thing grows exponentially.

> Argh, but unfortunately there will be issues to be ironed out with regard
> to reversibility of changes.  If the metarepo only holds the patch *names*
> of the subrepos, then there might be difficulties in (for example) the
> rollback of a patch that was removed from a subrepo.  Basically, the
> metarepo is only (in my head) versioning the metadata (i.e. patch names)
> stored in a subrepo, not the actual data itself (contents of the patches),
> some operations won't be truly reversible, which could wreak havoc on the
> patch theory.  On the other hand, the *inventories* of the subrepos would
> be fully reversibly managed, which may be enough to be useful.

Why would you only store the names? It seems to me that just as
recording copies your working files into current, recording changes to
a metarepo should copy (hardlink) the affected patches somewhere.

Incidentally, how about a repo being able to metaversion itself? It
seems like the idea of collecting groups of patches into a metapatch
(which I like very much) need not only apply in the case of multiple
subrepos, but could also completely replace tagging. That is, tagging
would become a special case in which metapatches form a non-commuting
chain. You could get that (if I'm understanding all this correctly) in
the current proposal using a metarepo containing just one repo, but it
doesn't seem like the metarepo then corresponds to anything
meaningful.

-- Jamie Webb




More information about the darcs-users mailing list