Message from David Roundy:

> darcs: --set-scripts-executable works partially
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328032

> Can you see if you can reproduce this bug? I don't get it, at least not
> with a remote get.  For a local get, --set-scripts-executable has no
> effect--which is a bug.  But I can't get darcs to leave "other" as
> non-executable while setting ug+x.

David, I should think this is probably the set-scripts-executable bug
for local gets.  Any reason you don't think so?

peace,

  isaac

On Mon, Dec 05, 2005 at 12:01:58AM +0000, Isaac Jones wrote:
> David, I should think this is probably the set-scripts-executable bug
> for local gets.  Any reason you don't think so?

No, that's probably the most likely explanation.  Extending
set-scripts-executable to work with local gets shouldn't be too hard.
-- 
David Roundy
http://www.darcs.net

This is supposed to be fixed in the unstable branch.  Please confirm.

David, do I or don't I close bugs when fixed in unstable?

                                        Juliusz

On Thu, Dec 15, 2005 at 12:10:44AM +0000, Juliusz Chroboczek wrote:
> This is supposed to be fixed in the unstable branch.  Please confirm.
> 
> David, do I or don't I close bugs when fixed in unstable?

I generally am torn.  I've toyed with the idea of adding support to roundup
to automatically close bugs based on darcs comments (or something of the
sort), which would allow us to close once by setting a roundup field as
"closedby: PATCHHASH", and have roundup tell users whether it's closed in a
particular branch of version of darcs (could even integrate with
--exact-version).  But that'd take a while to implement.

In the meantime, as a compromise it's perhaps best to remark that it's
closed in unstable in a comment, and let Tommy close it when it moves to
stable (or when he does a release?).
-- 
David Roundy
http://www.darcs.net

On Thu, Dec 15, 2005 at 01:05:03PM +0000, David Roundy wrote:
> In the meantime, as a compromise it's perhaps best to remark that it's
> closed in unstable in a comment, and let Tommy close it when it moves to
> stable (or when he does a release?).

I've added two new tags, resolved-in-unstable and resolved-in-stable.
Right now they both count as resolved, but it's easy to change the value of
their "resolution" status to make them show up as unresolved bugs (which
could save on duplicates).
-- 
David Roundy
http://www.darcs.net

(I keep flip-flopping on this...)

I just set resolved-in-stable and resolved-in-unstable to technically not
be resolved.  So now it shows up in the unresolved bug listing, but will be
marked as resolved-in-unstable, which should save it from getting
researched again.  You might also assign resolved-in-unstable bugs to Tommy
so they won't show up on the unassigned bug listing, which'll keep that
hopefully usefully clean for developers looking for something to work on.
-- 
David Roundy
http://www.darcs.net

fixed in 1.0.6
Sat Dec 10 22:51:22 CET 2005  kow@loria.fr
  * implementation of --set-scripts-executable on local darcs get