On Tue, Jan 31, 2006 at 05:11:09PM +0000, Jamie Webb wrote:
> While I agree that some sort of support for multiple projects would be
> very useful, this implementation has already been proposed, discussed,
> and another one chosen. No-one ever wrote the code though:
Yeah, I am aware of that discussion and have followed and participated
in other discussions on this topic on the list. however, the domains
proposal has a few key differences:
* it involves no changes to the patch or repo format. the two proposals
in that thread require adding a flag saying a directory is unique, or
some sort of addrepo, delrepo patch
* older versions of darcs will work with a project with domains just
fine, they just see a big repo because that is exactly what it is.
* (refering to the last proposal, involving subrepos) darcs is the
first revision control system that actually allows a powerful notion
of tree composition instead of mere aggregation like those other RCSs.
it seems like it would be a step backwards to add aggregation features
to darcs when it can do so much more, and in a simpler way too.
* 'domains' are not just for subrepositories, which is why I called them
domains and not modules or subprojects. As others have noted on this
list, the ability to have named subsets of your repo would be useful
for a number of reasons independent of subrepos. there is also a lot
of interesting design space to explore, overlapping domains,
intersection domains, etc.. which we may or may not ever find a use
for, but the point is the concept of a domain is a nice tool for the
darcs toolkit and fits the darcs philosophy well of providing basic
operations which you can build on. this basic tool happens to give you
the ability to do repository composition safely, but other uses are
likely to surface.
* domains are a whole lot easier to implement than the other proposals
* the 'poison patch' or 'antimatter - matter' patch pairs problem is a
hugely very serious issue facing darcs. serious enough to add support
for reducing the chances of it happening.
* domains are not independent repos when they are composed with other
projects, so you can 'tag' across all domains. this is also useful
when you must create local changes to a shared file. an instance would
be that I share doc between ginsu and jhc. doc has an instance which
conflicts with an instance with another library ginsu needs. it is
possible to make a patch in the ginsu repo that modifies the file in the
domain, but that patch itself is not a part of the domain. what it means
is the local copy in ginsu has the change, but that change won't be
propegated back into the main doc/ repo. this is a very useful feature.
This also makes moving files in and out of domains quite
straightforward. (however, when moving files into a domain, you will
probably want to check its history for any 'poison patches')
* the patch semantics are completly unaffected.
and most importantly:
* there is someone willing, ready, able, and desperate to implement
domains right now. (well, thursday)
John
--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
