Hello,

I have new 5 patches in my local repository, the first
4 of which I have already sent, so I just want to send
the fifth.

Darcs send goes through the first 4 (1/5, 2/5, 3/5 and 4/5)
asking me if I want to send them (to which I answer no), but
doesn't give me the option of sending patch 5/5.

But it _does_ include 5/5 if I answer yes to the first 4.

Regards
--
Adrian Hey

Adrian Hey wrote:
> Hello,
> 
> I have new 5 patches in my local repository, the first
> 4 of which I have already sent, so I just want to send
> the fifth.
> 
> Darcs send goes through the first 4 (1/5, 2/5, 3/5 and 4/5)
> asking me if I want to send them (to which I answer no), but
> doesn't give me the option of sending patch 5/5.
> 
> But it _does_ include 5/5 if I answer yes to the first 4.

OK, This doesn't seem to be specifically related to the
last patch. I've just recorded another (so I have 6 patches)
and darcs send still goes through (1/6)..(4/6) but doesn't
give me the option of sending (5/6) or (6/6).

I've also tried the latest snapshot build and have the same
problem.

Regards
-- 
Adrian Hey

Hi,

On Mon, Apr 09, 2007 at 16:46:46 +0000, Adrian Hey wrote:
> > Darcs send goes through the first 4 (1/5, 2/5, 3/5 and 4/5)
> > asking me if I want to send them (to which I answer no), but
> > doesn't give me the option of sending patch 5/5.
> > 
> > But it _does_ include 5/5 if I answer yes to the first 4.

It sounds like the 5th patch just depends on the 4th one, in which case,
this would be perfectly normal.  Are they related in any way?

Eric Y. Kow wrote:
> Hi,
> 
> On Mon, Apr 09, 2007 at 16:46:46 +0000, Adrian Hey wrote:
>>> Darcs send goes through the first 4 (1/5, 2/5, 3/5 and 4/5)
>>> asking me if I want to send them (to which I answer no), but
>>> doesn't give me the option of sending patch 5/5.
>>>
>>> But it _does_ include 5/5 if I answer yes to the first 4.
> 
> It sounds like the 5th patch just depends on the 4th one, in which case,
> this would be perfectly normal.  Are they related in any way?

Not AFAICS at a glance, but even if this is the explanation it seems
like a bug by design. At the very least I think darcs should offer
up some explanation to me of why it's not going to let me send a
particular patch.

But surely it should be up to me, seeing as I know the first 4 have
already been sent? The implications of this (if indeed this is what's
supposed to happen) is that I must resend patches whenever such
dependency occurs. That seems wrong to me.

BTW, the first 4 patches have not yet been pulled from the original
repository because they aren't there yet. But I have a feeling this
(alleged:-) problem might fix itself at that point. I'll let you know
what happens.

Regards
--
Adrian Hey

On Mon, Apr 09, 2007 at 18:36:11 +0100, Adrian Hey wrote:
> But surely it should be up to me, seeing as I know the first 4 have
> already been sent? The implications of this (if indeed this is what's
> supposed to happen) is that I must resend patches whenever such
> dependency occurs. That seems wrong to me.

Perhaps you should look into the --context feature of darcs changes and
darcs send.  It should allow you to overcome this problem.

Eric Kow wrote:
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> On Mon, Apr 09, 2007 at 18:36:11 +0100, Adrian Hey wrote:
>> But surely it should be up to me, seeing as I know the first 4 have
>> already been sent? The implications of this (if indeed this is what's
>> supposed to happen) is that I must resend patches whenever such
>> dependency occurs. That seems wrong to me.
> 
> Perhaps you should look into the --context feature of darcs changes and
> darcs send.  It should allow you to overcome this problem.

Thanks, but could you be a little more explicit about how this is
supposed to help?

e.g. I type..

 >darcs changes --last 2 --context > baba

this gives file baba:

Context:

[Misc typos and cleanup (no code changes)
Adrian Hey <ahey@iee.org>**20070408214555]

[Hiding some AVL modules
Adrian Hey <ahey@iee.org>**20070407235556]

then I type..

 >darcs send -o bubu --context baba
darcs: bug in get_extra commuting patch:
Sat Apr  7 20:48:06 GMT Standard Time 2007  Adrian Hey <ahey@iee.org>
   * Adds Data.Tree.AVL.Test.AllTests module

(bubu is not created)

Is this what you expected me to do? (and given that this is what I did,
is this what you'd expect darcs to do?)

If I try the context of last 6 patches, I get..
darcs: bug in get_extra commuting patch:
Sun Apr  1 06:35:37 GMT Standard Time 2007  jeanphilippe.bernardy@gmail.com
   * More fixes in cabal file (Thanks to Ross Paterson)

Thanks
--
Adrian Hey

On Mon, Apr 09, 2007 at 20:21:08 +0100, Adrian Hey wrote:
> >darcs changes --last 2 --context > baba
> 
> >darcs send -o bubu --context baba

That does sound like what I expected

> darcs: bug in get_extra commuting patch:
> Sat Apr  7 20:48:06 GMT Standard Time 2007  Adrian Hey <ahey@iee.org>
>   * Adds Data.Tree.AVL.Test.AllTests module

However, this does not.  David?

Marking as deferred, as this is likely a duplicate of issue175 (maybe we need a
'duplicate' status)

Eric Kow wrote:
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> Marking as deferred, as this is likely a duplicate of issue175 (maybe we need a
> 'duplicate' status)

Would it be useful to have a copy of the offending repository?
I'll zip the entire thing up as it is now, just in case anybody
decides they want to try and reproduce what I'm seeing. Let
me know if you'd like it.

Regards
--
Adrian Hey

> Would it be useful to have a copy of the offending repository?
> I'll zip the entire thing up as it is now, just in case anybody
> decides they want to try and reproduce what I'm seeing. Let
> me know if you'd like it.

I don't know how the others feel about it, but for me the essential
dilemma is that

 (i)   In principle, that would be *great*.  The more reproducible the
       cases, the better.
 (ii)  I personally don't have the time to look at it, perhaps someone
       else does
 (iii) I'm somewhat concerned about taking up space on darcs.net

If it's smallish (i.e. something you would imagine keeping around in
mail), sure, just attach it and the bug tracker will hold on to it.
Otherwise, I suppose the nicest solution would be to put it up on a
webserver somewhere and offer us a link, preferably until the day that
the bug gets fixed.

But that's just my personal view.

Hi Adrian,

At least  one of  the first four  patches is a  dependency of  the fifth
patch. This  likely means that the  fifth patch changes lines  that were
changed be one of the earlier patches.  So if you opt not to send them,
darcs cannot offer to send patch  number five because it would break the
dependency relationship.

I hope that helps.

Regards,

James.

On Mon, Apr 09, 2007 at 04:46:42PM +0000, Adrian Hey wrote:
> New submission from Adrian Hey <ahey@iee.org>:
> 
> Hello,
> 
> I have new 5 patches in my local repository, the first
> 4 of which I have already sent, so I just want to send
> the fifth.
> 
> Darcs send goes through the first 4 (1/5, 2/5, 3/5 and 4/5)
> asking me if I want to send them (to which I answer no), but
> doesn't give me the option of sending patch 5/5.
> 
> But it _does_ include 5/5 if I answer yes to the first 4.
> 
> Regards
> --
> Adrian Hey
> 
> ----------
> messages: 1564
> nosy: EricKow, ahey, beschmi, droundy, tommy
> status: unread
> title: Darcs send misses last patch (Windows 1.0.8)
> 
> ____________________________________
> Darcs issue tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue428>
> ____________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel

On Mon, Apr 09, 2007 at 06:36:11PM +0100, Adrian Hey wrote:
> At the very least I think darcs should offer
> up some explanation to me of why it's not going to let me send a
> particular patch.
> 
> But surely it should be up to me, seeing as I know the first 4 have
> already been sent? The implications of this (if indeed this is what's
> supposed to happen) is that I must resend patches whenever such
> dependency occurs. That seems wrong to me.

Perhaps darcs sometimes seems a little cryptic if you're used to
other tools. The 'Y' and 'N' in the send dialogue doesn't mean
if you want to just send them or not, but if you want the
patches to BE in the destination repository or not. That's why
darcs refuses you to select patch 5 is you say 'N' to patch 4,
since patch 5 would have to also put patch 4 in the destination
repository. The expected work flow is to answer 'W' (Wait) to
patches that you want darcs to automatically decide if they need
to be sent.

It is not a problem (for darcs) if the patches are sent a second
or third time. Darcs will not apply patches that are already in
the repository. So it is rather a feature; you can pick any sent
patch bundle with new patches of interest and apply it, and all
the dependency patches are guaranteed to be in it.

The extra work with context files is mostly for when you don't
have read access to the destination repository. It could be used
in your case to fake that the first four patches have already
been applied, but then you will get a patch bundle that _can't_
be applied until the first on has been, that is, you'll have to
manage all the dependencies yourself in your head. I'd say it's
not worth the extra work unless the patches are really really
big.

> BTW, the first 4 patches have not yet been pulled from the original
> repository because they aren't there yet. But I have a feeling this
> (alleged:-) problem might fix itself at that point. I'll let you know
> what happens.

Yes, this will "fix" the problem.

Hello,

I've put it here if anyone wants to try and reproduce this
sometime:

http://homepages.nildram.co.uk/~ahey/HLibs/collections-ghc66_BugState_09_04_07.zip 

Eric Y. Kow wrote:
>> Would it be useful to have a copy of the offending repository?
>> I'll zip the entire thing up as it is now, just in case anybody
>> decides they want to try and reproduce what I'm seeing. Let
>> me know if you'd like it.
> 
> I don't know how the others feel about it, but for me the essential
> dilemma is that
> 
>  (i)   In principle, that would be *great*.  The more reproducible the
>        cases, the better.
>  (ii)  I personally don't have the time to look at it, perhaps someone
>        else does
>  (iii) I'm somewhat concerned about taking up space on darcs.net
> 
> If it's smallish (i.e. something you would imagine keeping around in
> mail), sure, just attach it and the bug tracker will hold on to it.
> Otherwise, I suppose the nicest solution would be to put it up on a
> webserver somewhere and offer us a link, preferably until the day that
> the bug gets fixed.
> 
> But that's just my personal view.
>

On Mon, Apr 09, 2007 at 08:21:08PM +0100, Adrian Hey wrote:
> Thanks, but could you be a little more explicit about how this is
> supposed to help?
> 
> e.g. I type..
> 
> >darcs changes --last 2 --context > baba
>
> this gives file baba:
> 
> Context:
> 
> [Misc typos and cleanup (no code changes)
> Adrian Hey <ahey@iee.org>**20070408214555]
> 
> [Hiding some AVL modules
> Adrian Hey <ahey@iee.org>**20070407235556]

Hmmm.  I never thought about the combination of --last with --context, and
as a result, this is a bad context file.  What you want (I believe) is
really all but the last two patches to be in the context, as that'll
describe a repository that has everything but those you now want to send.
There are various ways you could get such a changes, none as easy as
--all-but-last 2 would be (except that it isn't implemented).

> then I type..
> 
> >darcs send -o bubu --context baba
> darcs: bug in get_extra commuting patch:
> Sat Apr  7 20:48:06 GMT Standard Time 2007  Adrian Hey <ahey@iee.org>
>   * Adds Data.Tree.AVL.Test.AllTests module
> 
> (bubu is not created)
> 
> Is this what you expected me to do? (and given that this is what I did,
> is this what you'd expect darcs to do?)
> 
> If I try the context of last 6 patches, I get..
> darcs: bug in get_extra commuting patch:
> Sun Apr  1 06:35:37 GMT Standard Time 2007  jeanphilippe.bernardy@gmail.com
>   * More fixes in cabal file (Thanks to Ross Paterson)

This is also wrong, a context really should always include all dependencies
of any patches listed, otherwise it's invalid.  So this really reflects a
bug in changes rather than a bug in send.  But I'm not quite sure what
changes should do in this case.  Either it should exit with an error
message, or output a different set of patches, neither of which seems ideal.
-- 
David Roundy
Department of Physics
Oregon State University

On Mon, Apr 09, 2007 at 07:58:01PM +0000, Eric Kow wrote:
> Marking as deferred, as this is likely a duplicate of issue175 (maybe we
> need a 'duplicate' status)

I don't think this is actually a duplicate, as I'd interpret this one as a
bug in changes, since changes is producing an invalid context.

darcs changes --context should always produce a "context" that describes a
set of patches that could exist in a repository.  This flag was added to
darcs (I believe) before we had all the change-selection flags, and doesn't
work well with them.

It's not clear whether darcs changes --last 2 --context should return a
context that includes all *but* the last two patches, or all the patches
that the last two depend on, or what.  Or what would darcs changes
--context -p foo return? All the patches named foo, plus their
dependencies, perhaps? I'm not sure.  Or in either of these cases it
*could* exit with a message that --context shouldn't be used in combination
with these flags.  I don't know what the correct behavior is, but we
definitely should fix this (someday).

And incidentally, this should be trivial to reproduce on any repository,
including that of darcs itself.  It could also be reproduced in a test case
for the test suite, just by recording three mutually dependent patches and
then creating a context containing just one and sending to that context.
-- 
David Roundy
Department of Physics
Oregon State University

Hello Folks,

Tommy Pettersson wrote:
> Perhaps darcs sometimes seems a little cryptic if you're used to
> other tools. The 'Y' and 'N' in the send dialogue doesn't mean
> if you want to just send them or not, but if you want the
> patches to BE in the destination repository or not.

Oh right, thanks. But considering the question darcs is
asking me, "no" seems like a perfectly reasonable and correct
response if the patch has already been sent.

So I still think it's a bug :-)

It'd be good if darcs could at least give some indication why
sending (5/6) and (6/6) was not allowed. e.g.

"Skipping (5/6) because of dependency on (3/6)."

Or maybe go through the list in reverse order, so at (5/6)
it asks:

"Shall I send this patch (5/6) and hence also patch (3/6)?"

With things as they are at the moment if I give the "wrong"
answer at patch (3/6) I don't get the opportunity to give
any answer at all for (5/6), with no explanation for this
strange behaviour from darcs.

Just an idea.

Regards
--
Adrian Hey

I am not sure what to do about this. I change to "need-volunteer", hoping that 
some volunteer will add some enlightening comments, at least.

Thanks and best regards
Thorkil

This is another one of these bugs from before we decided to be stricter about
not tracking more than one issue per bug.

* msg1564 - msg1568, msg1580 deal with some confusion due to the UI not telling
you about skipped dependencies.  That's resolved with issue125
* msg1570, msg1578, and especially msg1579 deal with a bug in darcs changes
--context.  This could either be resolved by figuring out what changes --context
is supposed to mean when you combine it with matchers (issue1597) or just
outright refuse them (issue1534)

In any case, I believe there is nothing left in this bug so I'm closing it as a
duplicate after all.

I've added all nosy folks here to the corresponding changes --context bugs.