Thanks for your answers, things are clearer now. The way I originally
understood your proposal was more ambitious than what you actually
proposed.
Just for the record, as I do not think it was spelled out: If there is
no domainfile, everything is in the same main domain and nothing
changes at all.
[John Meacham <[EMAIL PROTECTED]>, Wed, 1 Feb 2006 17:07:39 -0800]:
> it should be noted that without a --domain option then everything except
> for 'record' behaves exactly the same as if the domainfile didn't exist.
>
> the only difference in record is that it will interactivly prompt you in
> such a way that you can't produce a patch that crosses domain boundries.
And there should definitely be something like an --ignore-domains
switch that I can put into my preferences if I do not want to have
this behavior. Indeed, my preference would be that everything is
unchanged (even in the presence of a domainfile, and even for
`record`) as long as there is no --domain (or maybe
--restrict-patches-to-domains) switch that asks for modified behavior.
> however, you raise a good point that perhaps we should give the main
> domain a name
Well, what about the name being an empty string? I can see people
wanting to use any name you might come up with.
> I am not sure what you mean here. the domainfile is just a file
I see, your proposal is much more modest than what I thought. I
thought that pulling from some unrelated repo would put the pulled
stuff under a new domain so that, by default, new patches would not
touch both the old and the newly pulled files. But with your scheme
the puller has to add domain definitions manually to the domainfile.
> however, as part of implementing
> domains, I imagine I will extend the --match semantics in analogous ways
> as well. I would also add an '--exclusive-match' which would match
> patches that affect files matching the criteria _and nothing that
> affects files that don't match the criteria_
I don't think this is necessarily a good idea - somehow it reeks of
many ad-hoc changes piled on top of each other. At any rate, patch
matching is largely orthogonal to domains.
> > 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.
> there is no real need for this
My comment is another aspect of the more ambitious scheme I thought
you had proposed.
> > BTW, it seems to me that for the most part your domains are actually
> > the dependencies of the original adddir, addfile patches.
>
> almost, they are the dependencies of the original adddir,addfile minus
> patches that touch files outside the domain (and their dependencies).
> but yes, that is exactly the idea.
OK, so a domain is then everything that is either directly affected by
a given patch, or affected by a patch that does not affect anything
that is not affected by the domain of the original patch, and so on
(modulo special rules maybe for tags and replacements).
The advantage of defining domains in terms of patches are (apart from
flexibility and aesthetics) that it is then absolutely natural to also
have sets of lines, or even sets of tokens (in the sense of `darcs
replace`) as domains.
> however, I wanted to keep my
> initial proposal and implementation rather simple but leave room for
> future expansion.
But the basic concepts, I think, should be as general as possible from
the outset. It doesn't matter so much if only a particular type of
domain is implemented at first.
> When getting into things like overlapping domains then maintaining
> domain disjointness becomes a much trickier problem
But disjointness is not at all necessary, except for the particular
purpose you have in mind. What would disjointness bring you with,
e.g., restricting the tokens a `darcs replace` acts on? The concept
of a domain seems much more general than that of a means of avoiding
`poison' patches, and only those require disjointness.
> are you are just using domains for their aliasing abilities in those
> situations so perhaps we can have a flag in the domainfile saying 'this
> domain is allowed to overlap' which would make them behave normally for
> every command except that 'record' would ignore them.
I think that is exactly the wrong way round: If domains are general,
then properties like these flags should not be bound to the domains,
but the domains listed a certain restriction or property applies to.
E.g., with some random syntax, I could imagine a domainfile
(domainpolicyfile?) stating
(restricted-patches domain-foo)
(restricted-patches domain-bar)
(no-overlapping-patches
domain-foo
domain-bar
domain-baz)
(no-overlapping-replacements
domain-qux
domain-quux)
(no-overlapping-replacements
domain-qux
domain-quuux)
to express that, e.g., a patch touching domain-foo must not touch any
other domain; the same for bar; a patch touching domain-baz may touch
any domain except domain-foo or domain-bar; that replacements touching
domain-qux must not touch anything in domain-quux and vice versa; the
same for domain-qux and domain-quuux (whereas a replacement may span
domain-quux and domain-quuux because they are not in the same
no-overlapping-replacements clause); and that a patch touching any
other domain may touch any other domain (except as ruled out by the
other restrictions).
It seems to me that you are only thinking of the equivalent of the
restricted-patches clauses above because that is what applies to the
`poison' patches.
Regards,
Albert.
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
