[darcs-users] Subtitution of dependencies

[James Sleeman]

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).