On 14/09/12 01:09, Eric Kow wrote:
So do I understand correctly that what you're aiming at in this
hypothetical scenario is “push Patch 2 over even if it depends on
Patch 1 [and do whatever it takes to make it possible]”? Do you
actually want something conflict based, or would you for example,
prefer an alternative based on “breaking up” Patch 1 so that we can
ship over only the bits of it that matter?
I suspect that from a usage stand point, conflict based would be the
easiest way to do it. The reason is that, at least in my (limited)
experience, where I come across these problems is where the dependancy
because of some very small change (usually like, 1 line somewhere) in a
much larger patch, finding that dependancy is easy in a conflict resolution.
As you've described the problem, my current reflex would be to reach
for darcs rebase indeed, but am I missing something in wanting to do so?
I think that darcs rebase would help, but without having been able to
play with it (I was not successful in compiling last time I tried) I
don't know for sure. Here's hoping we can see rebase in an official
darcs release soon.
Thinking about it my situation of Trunk:Branch:Subbranch, lets say I
have written in Subbranch the following patches and pushed them "upline"
DestinedForTrunkPatch
DestinedForBranchPatch
SubBranchOnlyPatch
I think that with rebase though the problem arises when I now continue
working in Subbranch and add
AnotherDestinedForTrunkPatch
This new patch may have a dependancy (implicit) on any of the previous
patches, and would have to be rebased "above" DestinedForBranchPatch,
which I think would be a problem since that patch has been pushed
already (but perhaps I misunderstand how rebase will work, again haven't
tried it myself)?
Aside: For background, I presently (for the last, err, lots of years)
manage this Trunk:Branch:Subbranch setup essentially with subversion and
"svnmerge". Effectively, this is like if darcs didn't know anything
about implicit dependencies and just allowed you to pull anything you
want, and let the developer sort out making any changes that might be
needed, it works well enough, but darcs would be better in many ways if
only it wasn't for the implicit dependency problem.
So one random aside: Darcs' optimism but in a way
surprised/disappointed by the remaining bits of pessimism
What attracted me (and still does) to darcs initially, was the whole
cherry-picking idea which seemed on the face of it something that was
fundamental to the notion of darcs itself, where I could look at a
repository and say "I want THAT patch, not the rest". But when you get
down to it in the real world (at least mine), darcs says "I'll give you
that, but you HAVE to take all this other stuff you don't want as well".
In a way, implicit dependencies "surprised me", and I see them as
undesirable, or at least way more trouble than they are worth, I'd
frankly prefer if darcs gave me the patch I asked for and let me decide
how to meet the dependencies (perhaps with some helpful advice from
darcs though, in the form of conflicts).
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
