Not to thread jack Anthony's post, but sort of related here. I've also
been battling with dependancy issues, in my eternal evaluation of darcs
to see if I can use it for my main job (as opposed to the smaller
projects I use it with currently) loosely speaking, my code organization
(currently SVN managed) looks like
"Trunk Repo"
"Branch Repo 1"
"Sub Branch Repo A"
"Sub Branch Repo B"
"Branch Repo 2"
"Sub Branch Repo C"
"Sub Branch Repo D"
I work in the "Sub Branch" repositories, hack hack hack, and when I'm
done, I want to push/pull certain patches (cherry pick) from the Sub
Branch "up the line", some go to a "Branch Repo", some go to both
"Branch Repo" and "Trunk Repo" (specifically, "Trunk" is my master code,
"Branch Repo" is what a specific client prefers/code specific to them,
and "Sub Branch" is what a specific website requires/code specific to it).
Unfortunately, it just doesn't work in practice, because too often I get
stymied when a patch I want to push/pull implicitly depends on (for
whatever reason) one I don't want to pull. Of course, rebase might go
some way to helping there if I could rebase the patches first so the
ones I don't want are not being depended upon (are on the top of the
stack instead of somewhere further down), but it's not available, and
probably wouldn't solve all the problem.
Ideally from my horribly uneducated point of view, would be the
(fanciful) ability for there to be a "stand in" dependency patch, a
special case of a conflict resolution patch, which darcs sees as a
substitute for some set of patches we don't have but are depended upon
by something we want.
Example, "Repo D" contains Patch 1 and Patch 2 which depends on it.
I want to pull Patch 2 into "Repo 2", but not Patch 1.
What I'd really like to be able to do is say "darcs pull in Patch 2,
ignore the dependancy on Patch 1, and present any problems you have in
doing so as a conflict" ( something like: darcs pull -p"Patch 2"
--manually-resolve-dependancy="Patch 1" [sourcerepo] )
Then I'd resolve the conflict and record that patch as a "stand in" for
Patch 1, darcs would of course have to know that it's recording the
stand-in (something like: darcs record
--stand-in-for-missing-dependancy="Patch 1")
If at any time I brought in Patch 1, then it would "mask out" the stand
in patch
If I later pushed/pulled something that depended on my "stand in", then
the receiving end would not bring in the "Stand In" if that recipient
already had Patch 1, namely, "either Patch 1 if you have it, or this
stand in patch will satisfy the dependancy", and of course they could
also choose to manually resolve it and create their own stand in, as one
would expect.
Patch 1 can be extended to "Patch [1..n]" for all patches that are
dependend on that I don't want, and the stand-in would stand-in for that
set of patches. Bringing in any of those patches would mask-out the
stand in, and naturally produce conflicts to resolve (as a new stand in
for "Patch [1..n-m]")
Two stand ins covering the same set of patches (or an overlap), would
naturally conflict and require a conflict resolution of some description.
Anyway, just my idle musing.
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
