Some questions and thoughts on your proposal - I hope I have not missed anything in the discussion so far:
- Suppose we have two repos, A and B. Neither of these has a domainfile (or an empty one), so that everything in either repo belongs to the "unnamed main domain": > everything in the repo that is not listed [in a domainfile] is > considererd a part of the unnamed 'main' domain. Now I pull A into B. Are the pulled patches interpreted as pertaining to the same, now enlarged unnamed main domain of the repo, or do they somehow magically pick up a new domain? I think it should be the former (which corresponds to the current situation), but in that case I do not see how you get the effect you want. This reminds me of the "unique repo ID" idea that came up before. If it is the latter, does this mean that you would want to create a domainfile and add some autogenerated artificial domain to it? This is the only way things might be in different domains that I can see. But adding a file the user never wanted to have seems a bad idea. And without write access to B (or the bad old "unique repo ID") I do not quite see how `darcs get`-ting B into C, recording some change in C, and pulling that patch into A (which must end up in the same autogenerated domain to be meaningful) would work. - Another point: Repo A has some file foo, repo B has a different file foo. Domainfile A puts foo into domain bar, domainfile B puts foo into domain baz. How is the two foos being in different domains going to help with pulling B into A, and with keeping the two foos separate? It seems to me that the solution to this kind of problem would still require `darcs pull` and related operations to optionally perform some pulling-cum-renaming. E.g., one might then use (in A) `darcs pull --renaming 's/^/b-/' B` to ensure that A has foo in domain bar and b-foo in domain baz. Without that, an alternative would be to pull B into C, record the re-naming in C, pull C into A; from that point on, although the domains may prevent one from recording patches that are not pushable to B in a meaningful way, you would still have to use something like "unexportable patches" or a naming convention to avoid accidentally pushing the renaming patch to B. All in all I do not quite see how these domains are supposed to work in various situations, and I don't think they are sufficient to achieve what you seem to want. BTW, it seems to me that for the most part your domains are actually the dependencies of the original adddir, addfile patches. You could then get most of the desired effect by restricting operations according to dependency on arbitrary patches: domain names would then merely be abbreviations for 'depends on patch so-and-so'; at the same time, this would seem a very darcs-y - doesn't darcs really want to operate on patches all the time? - definition of the notion of a domain, one that could also be used, e.g., with other operations and for other uses. It would also be more flexible than the simple list of files. Best regards, Albert. _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
