hi

$ dr push ../../pacman

Fri Sep  1 15:51:51 CEST 2006  .
  * .
Shall I push this patch? (1/1)  [ynWvpxqadjk], or ? for help: y
Waiting for lock /home/vmiklos/darcs/pacman/_darcs/lock
(...)
Waiting for lock /home/vmiklos/darcs/pacman/_darcs/lock
Couldn't get lock /home/vmiklos/darcs/pacman/_darcs/lock

$ echo $?
0

this way from scripts you can't handle the "could not get lock" error :/

$ dr --version
1.0.8 (release)

udv / greetings,
VMiklos

That's odd.  Lock.getlock does an exitWith $ ExitFailure 1 when it can't get the
lock.  Ideas?

On Thu, Mar 08, 2007 at 11:36:55AM +0000, Eric Kow wrote:
> That's odd.  Lock.getlock does an exitWith $ ExitFailure 1 when it can't get the
> lock.  Ideas?

Maybe it's when the apply fails to get the lock? We could look at whether
we check the exit code of the remote "darcs apply".
-- 
David Roundy
http://www.darcs.net

On Thu, Mar 08, 2007 at 15:13:10 +0000, David Roundy wrote:
> Maybe it's when the apply fails to get the lock? We could look at whether
> we check the exit code of the remote "darcs apply".

But if I understand correctly, this applying to a local repository
(../../something).  In that case we don't invoke a new darcs, do we?

On Thu, Mar 08, 2007 at 09:17:07PM +0100, Eric Y. Kow wrote:
> On Thu, Mar 08, 2007 at 15:13:10 +0000, David Roundy wrote:
> > Maybe it's when the apply fails to get the lock? We could look at whether
> > we check the exit code of the remote "darcs apply".
> 
> But if I understand correctly, this applying to a local repository
> (../../something).  In that case we don't invoke a new darcs, do we?

We still invoke a new darcs, which does have the advantage of keeping the
code path close to the same in the two cases (local and remote push).  But
it might make sense to code a local push differently.  Actually, for a
local push, the most efficient approach would be to implement it as a cd
and pull, which wouldn't involve creating an intermediate patch bundle.
But then we'd have totally different code paths, which is a little scary,
and the remote push code path wouldn't be tested by the test suite at all.
-- 
David Roundy
Department of Physics
Oregon State University

Na Thu, Mar 08, 2007 at 09:17:07PM +0100, "Eric Y. Kow" <eric.kow@gmail.com> pisal(a):
> On Thu, Mar 08, 2007 at 15:13:10 +0000, David Roundy wrote:
> > Maybe it's when the apply fails to get the lock? We could look at whether
> > we check the exit code of the remote "darcs apply".
> 
> But if I understand correctly, this applying to a local repository
> (../../something).  In that case we don't invoke a new darcs, do we?

this is on darcs push, so we do invoke one imho

VMiklos

On Thu, Mar 08, 2007 at 21:18:48 +0000, David Roundy wrote:
> > > Maybe it's when the apply fails to get the lock? We could look at whether
> > > we check the exit code of the remote "darcs apply".
> > 
> > But if I understand correctly, this applying to a local repository
> > (../../something).  In that case we don't invoke a new darcs, do we?
> 
> We still invoke a new darcs, which does have the advantage of keeping the
> code path close to the same in the two cases (local and remote push).

Yep, RemoteApply.apply_via_local uses execPipeIgnoreError It would be
good for somebody to look into this, figure out why we do that and see
if we can just use exec.

I confirmed this bug with Darcs 2. The issue is that darcs calls a remote darcs
and doesn't propagate the return code back. 

Solutions could involve properly passing the return code back through from the
remote darcs call, or re-implementing a local darcs push so that a second
process is not involved. 

I could possibly create an automated test for this, but it would be annoying to
run in the test suite, because we'd have to wait for it to time out each time. 

  Mark

> I could possibly create an automated test for this, but it would be annoying to
> run in the test suite, because we'd have to wait for it to time out each time. 

hmm, why a conflict results in a timeout? there could be different error
codes for locking failure and conflicts.

thanks,
- VMiklos

On Thu, Jan 31, 2008 at 10:10:33AM -0000, VMiklos <bugs@darcs.net> wrote:
> hmm, why a conflict results in a timeout? there could be different error
> codes for locking failure and conflicts.

ah, i'm stupid. so here the idea: this issue is both about

1) conflicts
2) locking failure

does not result in exit code 1

fixing both and creating a test for conflicts could be fine.

thanks,
- VMiklos

On Thu, Jan 31, 2008 at 10:48:56AM -0000, VMiklos wrote:
> ah, i'm stupid. so here the idea: this issue is both about
> 
> 1) conflicts
> 2) locking failure
> 
> does not result in exit code 1
> 
> fixing both and creating a test for conflicts could be fine.

A test for this would be great!

David

On Thu, Jan 31, 2008 at 04:38:37PM -0000, David Roundy <bugs@darcs.net> wrote:
> A test for this would be great!

here is one:

----
#!/bin/sh
set -ev

test $DARCS || DARCS=$PWD/../darcs

rm -rf tempc
mkdir tempc
cd tempc
$DARCS init
echo foo > foo.c
$DARCS rec -Ax -alm init
cd ..
rm -rf temps
$DARCS get tempc temps
cd temps
echo server >> foo.c
$DARCS rec -Ax -alm server
cd ../tempc
echo client >> foo.c
$DARCS rec -Ax -alm client
if $DARCS push -a ../temps; then
        false
fi
cd ..
rm -rf tempc temps
----

basically it creates a conflict and if darcs push says everything went
fine then it bails out with an error since it should _not_ say
everything is ok.

- VMiklos

Thanks for the test vmiklos. I have added it to tests/ and send the patch to the
darcs-devel list. It already passed, because David Roundy had already submitted
a fix, based on your report. 

   Mark