> On Mon, Nov 14, 2005 at 09:24:50PM +0100, VMiklos wrote:
> > till now (1.0.4 release) i had a simple script:
> > if darcs --commands 2>&1|grep -q add; then
> >         echo "inside a repo"
> > else
> >         echo "outside a repo"
> > fi
> > 
> > but now (with 1.0.4) it reports always "inside a repo", as darcs --commands lists
> > "add" outside a repo, too
> > 
> > is there any reason why it does? maybe this is a bug?
> 
> Yes, this looks like a bug.  Would you mind reporting it to the BTS? A
> quick look suggests that amInRepository' is calling findRepository' rather
> than itself recursively, and I think that's the bug.  But that code's a bit
> subtle, so I'd prefer to have someone else also take a look at it (which
> would hopefully be the result of reporting it to bugs@darcs.net).  You can
> quote me in the bug report...
> -- 
> David Roundy
> http://www.darcs.net

udv / greetings,
VMiklos

Here's a patch.  It works for me, but I'd like there to be a bit more
testing on it before this goes into darcs-stable.  (and yes, I'm partly
sending it to bugs@darcs.net just to see how well sending a patch to the
bug tracker works.)

New patches:

[fix bug in amInRepository.
David Roundy <droundy@darcs.net>**20051117131208
 This is the bug that causes issue9.  I'm a bit uncertain about this
 patch--it looks obvious, but this is pretty subtle code.
] 
<
> {
hunk ./Repository.lhs 113
                  setCurrentDirectory ".."
                  cd' <- getCurrentDirectory
                  if cd' /= cd
-                     then findRepository' $
+                     then amInRepository' $
                          reverse (takeWhile (/='/') $ reverse cd)///dir
                      else return (Left $
                                   "You need to be in a repository directory" ++
}

Context:

[bump version to 1.0.5rc1
Tommy Pettersson <ptp@lysator.liu.se>**20051117111128] 
[Fixed documentation of DARCS_GET_HTTP with curl.
Daniel B�nzli <daniel.buenzli@epfl.ch>**20051117062547] 
[Flag superfluous input using Test::Builder
Florian Weimer <fw@deneb.enyo.de>**20051112160533

 This change makes sure that the test case that triggers this error
 condition fails in a clean way (especially if test planning is not used,
 but it should work with plans as well).
] 
[add --dont-edit-description opposite to --edit-description.
David Roundy <droundy@darcs.net>**20051116115632] 
[English and markup fixes.
Dave Love <fx@gnu.org>**20051114224845] 
[update web page to reflect 1.0.4 as latest stable source.
David Roundy <droundy@darcs.net>**20051113210144] 
[TAG 1.0.4
David Roundy <droundy@darcs.net>**20051113134431] 
Patch bundle hash:
1eb26b32230501b7d4400204b6e781ca2484388e

i can confirm - works here, too

[...]
> Context:
[...]
> [Fixed documentation of DARCS_GET_HTTP with curl.
> Daniel B???nzli <daniel.buenzli@epfl.ch>**20051117062547] 
          ^^^

In the original patch this is coded as \fc (Latin1 u with
dots).  Coded with UTF8 it would be \c3\bc, but in roundup
it is coded as \ef\bf\bd which I can't decrypt.

The patch can't be applied since darcs can't parse that
particular patchinfo (I think). It lists the very following
patchinfos as the place for the parse error.

On Fri, Nov 18, 2005 at 12:47:48PM +0000, Tommy Pettersson wrote:
> Tommy Pettersson <ptp@lysator.liu.se> added the comment:
> 
> [...]
> > Context:
> [...]
> > [Fixed documentation of DARCS_GET_HTTP with curl.
> > Daniel B???nzli <daniel.buenzli@epfl.ch>**20051117062547] 
>           ^^^
> 
> In the original patch this is coded as \fc (Latin1 u with
> dots).  Coded with UTF8 it would be \c3\bc, but in roundup
> it is coded as \ef\bf\bd which I can't decrypt.
> 
> The patch can't be applied since darcs can't parse that
> particular patchinfo (I think). It lists the very following
> patchinfos as the place for the parse error.

I'm resending to darcs-devel.  This little experiment just goes to show
that it isn't only windows that corrupts darcs patch bundles--emacs can do
it too!
-- 
David Roundy
http://www.darcs.net

On Fri, Nov 18, 2005 at 01:55:12PM +0000, David Roundy wrote:
> that it isn't only windows that corrupts darcs patch bundles--emacs can do
> it too!

Ah! :-)