On Wed, Feb 01, 2006 at 07:18:55PM +0100, Albert Reiner wrote:
> 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?
patches have no domain identity. at least none they take with them. for
a given repo state and a given domainfile, you can unambiguously say
whether a patch belongs to a domain or not and which one they belong to,
but this isn't something they take with them. they will be reinterpreted
in the context of whatever repository they are in.
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.
however, you raise a good point that perhaps we should give the main
domain a name, since there is no reason not to let someone pull
everything that isn't part of a subproject say, which could be a useful
operation. so perhaps we should just call it 'main'. an important
invarient is that if there is no domainfile or one that makes everything
part of the same domain then passing '--domain main' will produce the
exact same effects as if no domain were specified.
> 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.
I am not sure what you mean here. the domainfile is just a file in the
repository like any other and will be sent around via push's and pull's
just like normal.
> - 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?
domains only are interpreted in the repo you are pulling from. so if you
pull from A to B and specify --domain foo, then you will be prompted to
pull that patch and normal patch conflict resolution will apply (or if
the two foos share a history, then the patch very well might apply
cleanly) the important thing isn't the name given to the domain, but
rather that patches do not cross domain boundries.
for the purposes of commands other than 'record' you can effectivly
think of them as aliases for rather fancy '--match' commands that can't
currently be expressed in darcs. 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_
> 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.
there is no real need for this, there is no problem with different
people having different domains, since they are interpreted locally. you
may very well want to intpret them differently in a way that isn't
propegated between repos. (however, the real power of preventing 'poison
patches' comes from being able to propagate them) in fact, allowing a
_darcs/prefs/domainfile would make a lot of sense for people using
domains just for their 'aliasing' potential and it would make it
symmetric with 'boringfile' etc...
> 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.
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.
yeah, there are definitly more uses for domains that just subrepos
(which is why I chose the name I did) and there could and I expect would
be various ways to specify them such as saying 'anything that depends on
this patch is a member of the domain'. however, I wanted to keep my
initial proposal and implementation rather simple but leave room for
future expansion.
When getting into things like overlapping domains then maintaining
domain disjointness becomes a much trickier problem, however, chances
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 there is a
lot of potential here, but kept my initial proposal very basic and the
minimum to help prevent the 'poison patch' problem which has been a
serious issue in practice. However, perhaps that was a bad idea because
it seemed to have obscured why this actually needed to be added to
darcs I think from some of the responses I got.
John
--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
