I have a directory named 'data' (lowercase d).  If I try to modify a
file in it, I get this:

% darcs mv data/bloom.gz data/bloom

darcs failed:  Data/bloom.gz is inexistant.


Notice the capital D.  Similarly:

% darcs add data/blah
Skipping 'Data/blah' ... couldn't add parent directory 'Data' to repository

darcs failed:  No files were added


This is on OS X, which has a semi-case insensitive filesystem, which
is probably relevant.  E.g. I can do 'ls Data' and get the 'data'
directory back, but if I look at the results of
Directory.readDirectory, it's 'data'.

I can work around the problem by branching the repo, and the new repo
seems to accept changes in 'data'.  However, eventually this bug comes
back (I've already done the workaround a couple of times).

BTW, "x is inexistent" is pretty awkward wording.

Hi Evan,

What does `darcs show files | grep -i data` say?
Thanks,

Eric



On 8 February 2014 18:34, Evan Laforge <bugs@darcs.net> wrote:
>
> New submission from Evan Laforge <qdunkan@gmail.com>:
>
> I have a directory named 'data' (lowercase d).  If I try to modify a
> file in it, I get this:
>
> % darcs mv data/bloom.gz data/bloom
>
> darcs failed:  Data/bloom.gz is inexistant.
>
>
> Notice the capital D.  Similarly:
>
> % darcs add data/blah
> Skipping 'Data/blah' ... couldn't add parent directory 'Data' to repository
>
> darcs failed:  No files were added
>
>
> This is on OS X, which has a semi-case insensitive filesystem, which
> is probably relevant.  E.g. I can do 'ls Data' and get the 'data'
> directory back, but if I look at the results of
> Directory.readDirectory, it's 'data'.
>
> I can work around the problem by branching the repo, and the new repo
> seems to accept changes in 'data'.  However, eventually this bug comes
> back (I've already done the workaround a couple of times).
>
> BTW, "x is inexistent" is pretty awkward wording.
>
> ----------
> messages: 17169
> nosy: qdunkan
> status: unknown
> title: darcs refuses to edit files in subdirectory named 'data'
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Eric Kow <http://erickow.com>

Also, how about `darcs changes Data --summary`? (and `darcs changes
data --summary` too)
I'm curious to see what the patches think the filename is.

On 8 February 2014 18:37, Eric Kow <bugs@darcs.net> wrote:
>
> Eric Kow <kowey@darcs.net> added the comment:
>
> Hi Evan,
>
> What does `darcs show files | grep -i data` say?
> Thanks,
>
> Eric
>
>
>
> On 8 February 2014 18:34, Evan Laforge <bugs@darcs.net> wrote:
>>
>> New submission from Evan Laforge <qdunkan@gmail.com>:
>>
>> I have a directory named 'data' (lowercase d).  If I try to modify a
>> file in it, I get this:
>>
>> % darcs mv data/bloom.gz data/bloom
>>
>> darcs failed:  Data/bloom.gz is inexistant.
>>
>>
>> Notice the capital D.  Similarly:
>>
>> % darcs add data/blah
>> Skipping 'Data/blah' ... couldn't add parent directory 'Data' to repository
>>
>> darcs failed:  No files were added
>>
>>
>> This is on OS X, which has a semi-case insensitive filesystem, which
>> is probably relevant.  E.g. I can do 'ls Data' and get the 'data'
>> directory back, but if I look at the results of
>> Directory.readDirectory, it's 'data'.
>>
>> I can work around the problem by branching the repo, and the new repo
>> seems to accept changes in 'data'.  However, eventually this bug comes
>> back (I've already done the workaround a couple of times).
>>
>> BTW, "x is inexistent" is pretty awkward wording.
>>
>> ----------
>> messages: 17169
>> nosy: qdunkan
>> status: unknown
>> title: darcs refuses to edit files in subdirectory named 'data'
>>
>> __________________________________
>> Darcs bug tracker <bugs@darcs.net>
>> <http://bugs.darcs.net/issue2356>
>> __________________________________
>> _______________________________________________
>> darcs-devel mailing list
>> darcs-devel@darcs.net
>> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>
>
>
> --
> Eric Kow <http://erickow.com>
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Eric Kow <http://erickow.com>

% darcs show files | grep -i data               ~/src/seq/main elaforge@archy
./data
./data/README
./data/bloom
./data/bloom-perf
./data/pnovla
./data/pnovla-perf
./data/viola-sonata
./data/viola-sonata-perf

% darcs changes Data --summary
Changes to Data:

Tue Dec 15 08:16:05 PST 2009  qdunkan@gmail.com
  * import cleanups
... [omitted]
    R ./Data/Map.hs
    R ./Data/
...

Wed Sep 17 15:56:30 PDT 2008  qdunkan@gmail.com
  * use locally hacked version of Data.Map that adds toDescList, this
is a temporary hack until my upstream patch goes in

    M ./Cmd/Serialize.hs +7
    A ./Data/
    A ./Data/Map.hs
    M ./TODO -4 +9
    M ./Ui/Track.hs -1 +2
    M ./Util/Data.hs -1 +1



So this is interesting.  Apparently in the distant past there was
indeed a directory called Data.

Hi, Evan!

Which version of darcs are you using? I am asking because the latest
version does not feature the "is inexistant" wording anywhere in the
source code.

On Sat, Feb 8, 2014 at 11:42 PM, Evan Laforge <bugs@darcs.net> wrote:
>
> Evan Laforge <qdunkan@gmail.com> added the comment:
>
> % darcs show files | grep -i data               ~/src/seq/main elaforge@archy
> ./data
> ./data/README
> ./data/bloom
> ./data/bloom-perf
> ./data/pnovla
> ./data/pnovla-perf
> ./data/viola-sonata
> ./data/viola-sonata-perf
>
> % darcs changes Data --summary
> Changes to Data:
>
> Tue Dec 15 08:16:05 PST 2009  qdunkan@gmail.com
>   * import cleanups
> ... [omitted]
>     R ./Data/Map.hs
>     R ./Data/
> ...
>
> Wed Sep 17 15:56:30 PDT 2008  qdunkan@gmail.com
>   * use locally hacked version of Data.Map that adds toDescList, this
> is a temporary hack until my upstream patch goes in
>
>     M ./Cmd/Serialize.hs +7
>     A ./Data/
>     A ./Data/Map.hs
>     M ./TODO -4 +9
>     M ./Ui/Track.hs -1 +2
>     M ./Util/Data.hs -1 +1
>
>
>
> So this is interesting.  Apparently in the distant past there was
> indeed a directory called Data.
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Sincerely yours,
-- Daniil

It's 2.8.0 (release).  Not so old, though I see no longer the most
recent.  I'll try upgrading, here is the new error msg:

% d --version
2.8.4 (+ 1 patch)
% touch data/foo
% d add data/foo
Skipping 'Data/foo' ... couldn't add parent directory 'Data' to repository

darcs failed:  No files were added

% d mv data/bloom data/xyz

darcs failed:  Data/bloom is inexistant.

Interesting, error msg is still the same.  This is the latest OS X
binary from darcs.net so that msg would have to have been changed very
recently.

On Sat, Feb 8, 2014 at 11:49 AM, Dan Frumin <bugs@darcs.net> wrote:
>
> Dan Frumin <difrumin@gmail.com> added the comment:
>
> Hi, Evan!
>
> Which version of darcs are you using? I am asking because the latest
> version does not feature the "is inexistant" wording anywhere in the
> source code.
>
> On Sat, Feb 8, 2014 at 11:42 PM, Evan Laforge <bugs@darcs.net> wrote:
>>
>> Evan Laforge <qdunkan@gmail.com> added the comment:
>>
>> % darcs show files | grep -i data               ~/src/seq/main elaforge@archy
>> ./data
>> ./data/README
>> ./data/bloom
>> ./data/bloom-perf
>> ./data/pnovla
>> ./data/pnovla-perf
>> ./data/viola-sonata
>> ./data/viola-sonata-perf
>>
>> % darcs changes Data --summary
>> Changes to Data:
>>
>> Tue Dec 15 08:16:05 PST 2009  qdunkan@gmail.com
>>   * import cleanups
>> ... [omitted]
>>     R ./Data/Map.hs
>>     R ./Data/
>> ...
>>
>> Wed Sep 17 15:56:30 PDT 2008  qdunkan@gmail.com
>>   * use locally hacked version of Data.Map that adds toDescList, this
>> is a temporary hack until my upstream patch goes in
>>
>>     M ./Cmd/Serialize.hs +7
>>     A ./Data/
>>     A ./Data/Map.hs
>>     M ./TODO -4 +9
>>     M ./Ui/Track.hs -1 +2
>>     M ./Util/Data.hs -1 +1
>>
>>
>>
>> So this is interesting.  Apparently in the distant past there was
>> indeed a directory called Data.
>>
>> __________________________________
>> Darcs bug tracker <bugs@darcs.net>
>> <http://bugs.darcs.net/issue2356>
>> __________________________________
>> _______________________________________________
>> darcs-devel mailing list
>> darcs-devel@darcs.net
>> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>
>
>
> --
> Sincerely yours,
> -- Daniil
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________

Thanks, Evan.

Did `darcs changes data --summary` show any results as well? Or was it
just `darcs changes Data --summary` that did?

At the very least, we can see that there are patches on the path with
big D Data…

Hmm.
No clear thinking on my part, yet, I'm afraid


On 8 February 2014 20:12, Evan Laforge <bugs@darcs.net> wrote:
>
> Evan Laforge <qdunkan@gmail.com> added the comment:
>
> It's 2.8.0 (release).  Not so old, though I see no longer the most
> recent.  I'll try upgrading, here is the new error msg:
>
> % d --version
> 2.8.4 (+ 1 patch)
> % touch data/foo
> % d add data/foo
> Skipping 'Data/foo' ... couldn't add parent directory 'Data' to repository
>
> darcs failed:  No files were added
>
> % d mv data/bloom data/xyz
>
> darcs failed:  Data/bloom is inexistant.
>
> Interesting, error msg is still the same.  This is the latest OS X
> binary from darcs.net so that msg would have to have been changed very
> recently.
>
> On Sat, Feb 8, 2014 at 11:49 AM, Dan Frumin <bugs@darcs.net> wrote:
>>
>> Dan Frumin <difrumin@gmail.com> added the comment:
>>
>> Hi, Evan!
>>
>> Which version of darcs are you using? I am asking because the latest
>> version does not feature the "is inexistant" wording anywhere in the
>> source code.
>>
>> On Sat, Feb 8, 2014 at 11:42 PM, Evan Laforge <bugs@darcs.net> wrote:
>>>
>>> Evan Laforge <qdunkan@gmail.com> added the comment:
>>>
>>> % darcs show files | grep -i data               ~/src/seq/main elaforge@archy
>>> ./data
>>> ./data/README
>>> ./data/bloom
>>> ./data/bloom-perf
>>> ./data/pnovla
>>> ./data/pnovla-perf
>>> ./data/viola-sonata
>>> ./data/viola-sonata-perf
>>>
>>> % darcs changes Data --summary
>>> Changes to Data:
>>>
>>> Tue Dec 15 08:16:05 PST 2009  qdunkan@gmail.com
>>>   * import cleanups
>>> ... [omitted]
>>>     R ./Data/Map.hs
>>>     R ./Data/
>>> ...
>>>
>>> Wed Sep 17 15:56:30 PDT 2008  qdunkan@gmail.com
>>>   * use locally hacked version of Data.Map that adds toDescList, this
>>> is a temporary hack until my upstream patch goes in
>>>
>>>     M ./Cmd/Serialize.hs +7
>>>     A ./Data/
>>>     A ./Data/Map.hs
>>>     M ./TODO -4 +9
>>>     M ./Ui/Track.hs -1 +2
>>>     M ./Util/Data.hs -1 +1
>>>
>>>
>>>
>>> So this is interesting.  Apparently in the distant past there was
>>> indeed a directory called Data.
>>>
>>> __________________________________
>>> Darcs bug tracker <bugs@darcs.net>
>>> <http://bugs.darcs.net/issue2356>
>>> __________________________________
>>> _______________________________________________
>>> darcs-devel mailing list
>>> darcs-devel@darcs.net
>>> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>>
>>
>>
>> --
>> Sincerely yours,
>> -- Daniil
>>
>> __________________________________
>> Darcs bug tracker <bugs@darcs.net>
>> <http://bugs.darcs.net/issue2356>
>> __________________________________
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Eric Kow <http://erickow.com>

On Sat, Feb 8, 2014 at 12:41 PM, Eric Kow <kowey@darcs.net> wrote:
> Thanks, Evan.
>
> Did `darcs changes data --summary` show any results as well? Or was it
> just `darcs changes Data --summary` that did?

'darcs changes data --summary' does the same capitalization trick as
all the other darcs commands, so I get the same output as the one for
Data.

Hmm

So we have evidence of patches from some distant past that refer to Data.

And we have your repository in its current state with data.

What I'm wondering about now is how we got from Data to data.

If you do a darcs get, is it 'data' you see and not 'Data'?
I'm puzzled about why you don't see patches that refer to 'data'

Maybe a useful thing might be to darcs changes --summary | less and
search for \./data

(BTW, I'm bound to confuse myself here with the case-insensitive-ish
filesystem, this weirdness about being able to remember case (which is
nice) but look up filenames in a case-insensitive way)


On 8 February 2014 20:46, Evan Laforge <bugs@darcs.net> wrote:
>
> Evan Laforge <qdunkan@gmail.com> added the comment:
>
> On Sat, Feb 8, 2014 at 12:41 PM, Eric Kow <kowey@darcs.net> wrote:
>> Thanks, Evan.
>>
>> Did `darcs changes data --summary` show any results as well? Or was it
>> just `darcs changes Data --summary` that did?
>
> 'darcs changes data --summary' does the same capitalization trick as
> all the other darcs commands, so I get the same output as the one for
> Data.
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Eric Kow <http://erickow.com>

On Sat, Feb 8, 2014 at 1:04 PM, Eric Kow <kowey@darcs.net> wrote:
> Hmm
>
> So we have evidence of patches from some distant past that refer to Data.
>
> And we have your repository in its current state with data.
>
> What I'm wondering about now is how we got from Data to data.
>
> If you do a darcs get, is it 'data' you see and not 'Data'?
> I'm puzzled about why you don't see patches that refer to 'data'

I see 'data'.

> Maybe a useful thing might be to darcs changes --summary | less and
> search for \./data

I do see the 'data' patches as expected.  I can work around the
problem by making a branch and recording changes to 'data' on that.  I
can even continue to use the original branch by pulling the patch
over.

It behaves as if the confusion happens only at the UI level.  The
actual patches are not confused.

> (BTW, I'm bound to confuse myself here with the case-insensitive-ish
> filesystem, this weirdness about being able to remember case (which is
> nice) but look up filenames in a case-insensitive way)

Indeed, I'm pretty sure this is what is triggering the bug in darcs.

I am running darcs 2.9.8 [1] and even thought I cannot reproduce the
exact same bug I stumbled upon this data/Data confusion too:

% darcs changes "data" --summary
Changes to data:

Sat Feb  8 23:48:11 MSK 2014  Dan Frumin <difrumin@gmail.com>
  * foobar

     ./data/foo -> ./data/bar

Sat Feb  8 23:47:17 MSK 2014  Dan Frumin <difrumin@gmail.com>
  * adding data

    A ./data/
    A ./data/foo

% darcs changes "Data" --summary
Changes to data:

Sat Feb  8 23:48:11 MSK 2014  Dan Frumin <difrumin@gmail.com>
  * foobar

     ./data/foo -> ./data/bar

Sat Feb  8 23:47:17 MSK 2014  Dan Frumin <difrumin@gmail.com>
  * adding data

    A ./data/
    A ./data/foo


Even though I had added the Data folder and removed it.

I've uploaded the repository for reference:
http://hub.darcs.net/co-dan/data_issue2356/changes

I can not replicate this behaviour on Linux so this is indeed a sort
of interface bug in some part of the code that deals with a file
system.


[1] http://darcs.covariant.me/darcs-2.9-OSX-10.8-x86_64.tgz

On Sun, Feb 9, 2014 at 12:46 AM, Evan Laforge <bugs@darcs.net> wrote:
>
> Evan Laforge <qdunkan@gmail.com> added the comment:
>
> On Sat, Feb 8, 2014 at 12:41 PM, Eric Kow <kowey@darcs.net> wrote:
>> Thanks, Evan.
>>
>> Did `darcs changes data --summary` show any results as well? Or was it
>> just `darcs changes Data --summary` that did?
>
> 'darcs changes data --summary' does the same capitalization trick as
> all the other darcs commands, so I get the same output as the one for
> Data.
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Sincerely yours,
-- Daniil

Hi Dan,

> I've uploaded the repository for reference:
> http://hub.darcs.net/co-dan/data_issue2356/changes

Thanks for boiling this down into a minimal repository!
If I understand correctly, we haven't yet reproduced Evan's bug
(what we want is to create a situation where eg if you said
darcs mv data/bar data/quux, it would complain about Data/bar),
but it does help us to get some insight.

Snipping your log below to summarise

> % darcs changes "data" --summary
> ./data/foo -> ./data/bar
> A ./data/
> A ./data/foo
> % darcs changes "Data" --summary
[idem]

Look at this:

$ darcs changes --match 'touch data' --summary | grep -i '\./data'
     ./data/foo -> ./data/bar
    A ./data/
    A ./data/foo

$ darcs changes --match 'touch Data' --summary | grep -i '\./data'
    R ./Data/Foo
    R ./Data/
    A ./Data/
    A ./Data/Foo

So Dan! This won't help much, but if you're keen for some Darcs exploration, it might be interesting to dig through the code to try and work out what darcs does differently when given the Touch matcher (which inspects the patch contents), and when given a path on the command line. It'd be an interesting exercise, good thing to figure out why the two outputs are different. (I unfortunately don't know/remember the code well enough to give more clues, maybe some sort of local file tree in memory).

Another thing that's useful to observe is that in the absence of any bugs, it's quite possible to defeat darcs's refusal-by-default to add files whose names are identical to other files modulo case differences. You just need a remove and a commute. This isn't a big problem in and of itself, but it's useful to be aware.



--  
http://erickow.com

Thanks, Evan

If I may try your patience a bit further.

On 8 February 2014 at 21:55:23, Evan Laforge (bugs@darcs.net) wrote:
> > If you do a darcs get, is it 'data' you see and not 'Data'?
> > I'm puzzled about why you don't see patches that refer to 'data'  
>  
> I see 'data'.

OK so darcs get gives you 'data'
 
> > Maybe a useful thing might be to darcs changes --summary | less  
> and
> > search for \./data
>  
> I do see the 'data' patches as expected. 

Ah, in addition to the Data patches?

Hmm, I've thought of another way to search the patch history.
Could you please attach the full output of

   darcs changes --summary --match "touch [dD]ata"

This should by rights give us the list of patches to both small and big d
data.

> I can work around the
> problem by making a branch and recording changes to 'data' on  
> that. I
> can even continue to use the original branch by pulling the patch  
> over.

OK, it's good to hear you have a work-around (at least until Darcs gets confused again).

Hopefully with your list of patches, we will be able to work out why Darcs insists that big D data should still be there and maybe come up with a longer lasting solution for you, and either some UI improvements or bugfixes to darcs.

--  
http://erickow.com

>> > Maybe a useful thing might be to darcs changes --summary | less
>> and
>> > search for \./data
>>
>> I do see the 'data' patches as expected.
>
> Ah, in addition to the Data patches?

Yep.

> Hmm, I've thought of another way to search the patch history.
> Could you please attach the full output of
>
>    darcs changes --summary --match "touch [dD]ata"
>
> This should by rights give us the list of patches to both small and big d
> data.

Indeed it does, I see both the old add Data/ then remove Data/, and
then the new add data/, followed by modifications of files inside.

> Hopefully with your list of patches, we will be able to work out why Darcs insists that big D data should still be there and maybe come up with a longer lasting solution for you, and either some UI improvements or bugfixes to darcs.

The repo has 3617 patches, dating from 2008, so it's not exactly a
minimal reproduction, but if examining the current state would help I
could give you access... it's something I plan to eventually open
source anyway.  Actually, that probably wouldn't help, because I'd
have to give you access to a branch, and branches tend to not have the
problem any more.  I could try just copying directly, but you'd have
to copy it to another OS X machine to get a repro.  The _darcs
directory is 43mb.

One other bit is that it started in the darcs1 format and was later
upgraded.  I wouldn't be surprised if the Data directory dated from
the darcs1 era.  However, my main branch has gone through a few 'darcs
get's, so I don't think any of the original darcs files remain.

On 10 February 2014 at 18:37:08, Evan Laforge (bugs@darcs.net) wrote:

> The repo has 3617 patches, dating from 2008, so it's not exactly  
> a
> minimal reproduction, but if examining the current state would  
> help I
> could give you access... 

So, I don't think full access would be needed.  Maybe something like this would tell me what I need to know

    darcs changes --match 'touch [dD]ata' --summary | grep '\(^  \*\|\./data*\)' -i

Basically grepping both the filename and also the '  *' patch bullet point

What I would like to see is if we can somehow reliably recreate darcs being unhelpful with the case thing.  What is interesting is that if I understand correctly, it's not just the history because when do a get things seem to work for a while (which leads me by the way to suspect that things work for the “wrong” reason, and maybe with darcs get --no-cache you might find something weird and interesting)

> One other bit is that it started in the darcs1 format and was later 
> upgraded. I wouldn't be surprised if the Data directory dated  
> from

Interesting, thanks! I don't have any reason to believe that this would affect things, but then of course, if I knew what was wrong, we wouldn't be doing all this poking

Thanks again!

--  
http://erickow.com

On Tue, Feb 11, 2014 at 12:15 AM, Eric Kow <bugs@darcs.net> wrote:
>
> Eric Kow <kowey@darcs.net> added the comment:
>
> On 10 February 2014 at 18:37:08, Evan Laforge (bugs@darcs.net) wrote:
>
>> The repo has 3617 patches, dating from 2008, so it's not exactly
>> a
>> minimal reproduction, but if examining the current state would
>> help I
>> could give you access...
>
> So, I don't think full access would be needed.  Maybe something like this would tell me what I need to know
>
>     darcs changes --match 'touch [dD]ata' --summary | grep '\(^  \*\|\./data*\)' -i
>
> Basically grepping both the filename and also the '  *' patch bullet point

Here you go:

  * rename synths to non-abbreviated names
    M ./data/bloom
    M ./data/bloom-perf
    M ./data/pnovla
    M ./data/pnovla-perf
    M ./data/viola-sonata
  * remove .gz suffix from saved states
     ./data/bloom-perf.gz -> ./data/bloom-perf
     ./data/bloom.gz -> ./data/bloom
     ./data/pnovla-perf.gz -> ./data/pnovla-perf
     ./data/pnovla.gz -> ./data/pnovla
     ./data/viola-sonata-perf.gz -> ./data/viola-sonata-perf
     ./data/viola-sonata.gz -> ./data/viola-sonata
  * make velocity come from control functions so it can be randomized
    M ./data/bloom-perf.gz
    M ./data/pnovla-perf.gz
    M ./data/viola-sonata-perf.gz
  * make Derive.Call.Util.pitched_note only take pitch, not pitch and dynamic
    M ./data/viola-sonata-perf.gz
  * add Ui.StateConfig.Performance, which lets me save a "last known
good" performance with each score
    M ./data/bloom-perf.gz
    M ./data/pnovla-perf.gz
    M ./data/viola-sonata-perf.gz
  * update data/viola-sonata-perf.gz
    M ./data/viola-sonata-perf.gz
  * make Derive.with_instrument throw if the instrument doesn't exist
    M ./data/viola-sonata.gz
  * split generator and transformer calls
    M ./data/bloom-perf.gz
    M ./data/bloom.gz
    M ./data/viola-sonata-perf.gz
  * update regression tests, broken when I fixed midi channel allotment
    M ./data/bloom-perf.gz
    M ./data/pnovla-perf.gz
  * fix bug where midi events can be slightly out of order
    M ./data/bloom-perf.gz
    M ./data/pnovla-perf.gz
    M ./data/viola-sonata-perf.gz
  * update regression tests, and add viola-sonata
    M ./data/bloom-perf.gz
    A ./data/viola-sonata-perf.gz
    A ./data/viola-sonata.gz
  * add Derive.Regression_test
    A ./data/
    A ./data/README
    A ./data/bloom-perf.gz
    A ./data/bloom.gz
    A ./data/pnovla-perf.gz
    A ./data/pnovla.gz
  * import cleanups
    R ./Data/Map.hs
    R ./Data/
  * split Util.Data into Util.Array and Util.Map
  * expand InputKeys into InputNote with continuous pitch support,
working midi thru, add rdev and wdev state, don't pass chan map from
Cmd state
  * implement skeleton with Data.Graph instead of custom tree to make
toggle_edge easier to implement
  * implement background derivation
  * use locally hacked version of Data.Map that adds toDescList, this
is a temporary hack until my upstream patch goes in
    A ./Data/
    A ./Data/Map.hs
  * add Util.Debug.timer and nicer test formatting
  * clean up misc stuff in tests
  * implement Cmd.Simple loading, initial clipboard implementation
  * clean instrument names, warn about overlapping instruments, remove
PatchTemplate
  * implement Signal.equal
  * remove_events deletes 0 dur events
  * fix zero duration event bug
  * put instrument in the event, fix channelize bug, ReadMessage and
WriteMessage are real types
  * misc Util cleanups and additions
  * move Util.Array to more general Util.Data

> What I would like to see is if we can somehow reliably recreate darcs being unhelpful with the case thing.  What is interesting is that if I understand correctly, it's not just the history because when do a get things seem to work for a while (which leads me by the way to suspect that things work for the “wrong” reason, and maybe with darcs get --no-cache you might find something weird and interesting)

Indeed, this is what makes it tricky.  I've actually only had it come
back once so far, but it's probably mostly because I only very rarely
edit files in that directory.  Basically, at some point within the
last 6 months, I had the data Data problem, and figured out that I
could get a branch and it didn't have the problem.  So I deleted my
old main branch and moved the new working one to main.  Then recently
I went to edit files in data/ again and the problem had come back.  So
it takes something under 6 months worth of patches (more or less.. I
don't remember exactly which patch back there required the workaround)
to come back.  Possibly much less, but it's hard to know since I so
rarely modify files in data/.


BTW, this is surely unrelated, by why do all of the paths in --summary
start with ./?  Isn't that redundant?

Thanks, Evan!

Hi Dan, is there any chance you'd be able to have a look at Evan's log
here and try to recreate a minimal repository that roughly mirrors the
relevant bits of his patch history?



On 12 February 2014 06:42, Evan Laforge <bugs@darcs.net> wrote:
>
> Evan Laforge <qdunkan@gmail.com> added the comment:
>
> On Tue, Feb 11, 2014 at 12:15 AM, Eric Kow <bugs@darcs.net> wrote:
>>
>> Eric Kow <kowey@darcs.net> added the comment:
>>
>> On 10 February 2014 at 18:37:08, Evan Laforge (bugs@darcs.net) wrote:
>>
>>> The repo has 3617 patches, dating from 2008, so it's not exactly
>>> a
>>> minimal reproduction, but if examining the current state would
>>> help I
>>> could give you access...
>>
>> So, I don't think full access would be needed.  Maybe something like this would tell me what I need to know
>>
>>     darcs changes --match 'touch [dD]ata' --summary | grep '\(^  \*\|\./data*\)' -i
>>
>> Basically grepping both the filename and also the '  *' patch bullet point
>
> Here you go:
>
>   * rename synths to non-abbreviated names
>     M ./data/bloom
>     M ./data/bloom-perf
>     M ./data/pnovla
>     M ./data/pnovla-perf
>     M ./data/viola-sonata
>   * remove .gz suffix from saved states
>      ./data/bloom-perf.gz -> ./data/bloom-perf
>      ./data/bloom.gz -> ./data/bloom
>      ./data/pnovla-perf.gz -> ./data/pnovla-perf
>      ./data/pnovla.gz -> ./data/pnovla
>      ./data/viola-sonata-perf.gz -> ./data/viola-sonata-perf
>      ./data/viola-sonata.gz -> ./data/viola-sonata
>   * make velocity come from control functions so it can be randomized
>     M ./data/bloom-perf.gz
>     M ./data/pnovla-perf.gz
>     M ./data/viola-sonata-perf.gz
>   * make Derive.Call.Util.pitched_note only take pitch, not pitch and dynamic
>     M ./data/viola-sonata-perf.gz
>   * add Ui.StateConfig.Performance, which lets me save a "last known
> good" performance with each score
>     M ./data/bloom-perf.gz
>     M ./data/pnovla-perf.gz
>     M ./data/viola-sonata-perf.gz
>   * update data/viola-sonata-perf.gz
>     M ./data/viola-sonata-perf.gz
>   * make Derive.with_instrument throw if the instrument doesn't exist
>     M ./data/viola-sonata.gz
>   * split generator and transformer calls
>     M ./data/bloom-perf.gz
>     M ./data/bloom.gz
>     M ./data/viola-sonata-perf.gz
>   * update regression tests, broken when I fixed midi channel allotment
>     M ./data/bloom-perf.gz
>     M ./data/pnovla-perf.gz
>   * fix bug where midi events can be slightly out of order
>     M ./data/bloom-perf.gz
>     M ./data/pnovla-perf.gz
>     M ./data/viola-sonata-perf.gz
>   * update regression tests, and add viola-sonata
>     M ./data/bloom-perf.gz
>     A ./data/viola-sonata-perf.gz
>     A ./data/viola-sonata.gz
>   * add Derive.Regression_test
>     A ./data/
>     A ./data/README
>     A ./data/bloom-perf.gz
>     A ./data/bloom.gz
>     A ./data/pnovla-perf.gz
>     A ./data/pnovla.gz
>   * import cleanups
>     R ./Data/Map.hs
>     R ./Data/
>   * split Util.Data into Util.Array and Util.Map
>   * expand InputKeys into InputNote with continuous pitch support,
> working midi thru, add rdev and wdev state, don't pass chan map from
> Cmd state
>   * implement skeleton with Data.Graph instead of custom tree to make
> toggle_edge easier to implement
>   * implement background derivation
>   * use locally hacked version of Data.Map that adds toDescList, this
> is a temporary hack until my upstream patch goes in
>     A ./Data/
>     A ./Data/Map.hs
>   * add Util.Debug.timer and nicer test formatting
>   * clean up misc stuff in tests
>   * implement Cmd.Simple loading, initial clipboard implementation
>   * clean instrument names, warn about overlapping instruments, remove
> PatchTemplate
>   * implement Signal.equal
>   * remove_events deletes 0 dur events
>   * fix zero duration event bug
>   * put instrument in the event, fix channelize bug, ReadMessage and
> WriteMessage are real types
>   * misc Util cleanups and additions
>   * move Util.Array to more general Util.Data
>
>> What I would like to see is if we can somehow reliably recreate darcs being unhelpful with the case thing.  What is interesting is that if I understand correctly, it's not just the history because when do a get things seem to work for a while (which leads me by the way to suspect that things work for the “wrong” reason, and maybe with darcs get --no-cache you might find something weird and interesting)
>
> Indeed, this is what makes it tricky.  I've actually only had it come
> back once so far, but it's probably mostly because I only very rarely
> edit files in that directory.  Basically, at some point within the
> last 6 months, I had the data Data problem, and figured out that I
> could get a branch and it didn't have the problem.  So I deleted my
> old main branch and moved the new working one to main.  Then recently
> I went to edit files in data/ again and the problem had come back.  So
> it takes something under 6 months worth of patches (more or less.. I
> don't remember exactly which patch back there required the workaround)
> to come back.  Possibly much less, but it's hard to know since I so
> rarely modify files in data/.
>
>
> BTW, this is surely unrelated, by why do all of the paths in --summary
> start with ./?  Isn't that redundant?
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Eric Kow <http://erickow.com>

Hi, Eric and Evan

I tried recreating the repository, but to no avail:
http://hub.darcs.net/co-dan/2356
I still can't get the error Evan is experiencing :(

On Wed, Feb 12, 2014 at 1:19 PM, Eric Kow <bugs@darcs.net> wrote:
>
> Eric Kow <kowey@darcs.net> added the comment:
>
> Thanks, Evan!
>
> Hi Dan, is there any chance you'd be able to have a look at Evan's log
> here and try to recreate a minimal repository that roughly mirrors the
> relevant bits of his patch history?
>
>
>
> On 12 February 2014 06:42, Evan Laforge <bugs@darcs.net> wrote:
>>
>> Evan Laforge <qdunkan@gmail.com> added the comment:
>>
>> On Tue, Feb 11, 2014 at 12:15 AM, Eric Kow <bugs@darcs.net> wrote:
>>>
>>> Eric Kow <kowey@darcs.net> added the comment:
>>>
>>> On 10 February 2014 at 18:37:08, Evan Laforge (bugs@darcs.net) wrote:
>>>
>>>> The repo has 3617 patches, dating from 2008, so it's not exactly
>>>> a
>>>> minimal reproduction, but if examining the current state would
>>>> help I
>>>> could give you access...
>>>
>>> So, I don't think full access would be needed.  Maybe something like this would tell me what I need to know
>>>
>>>     darcs changes --match 'touch [dD]ata' --summary | grep '\(^  \*\|\./data*\)' -i
>>>
>>> Basically grepping both the filename and also the '  *' patch bullet point
>>
>> Here you go:
>>
>>   * rename synths to non-abbreviated names
>>     M ./data/bloom
>>     M ./data/bloom-perf
>>     M ./data/pnovla
>>     M ./data/pnovla-perf
>>     M ./data/viola-sonata
>>   * remove .gz suffix from saved states
>>      ./data/bloom-perf.gz -> ./data/bloom-perf
>>      ./data/bloom.gz -> ./data/bloom
>>      ./data/pnovla-perf.gz -> ./data/pnovla-perf
>>      ./data/pnovla.gz -> ./data/pnovla
>>      ./data/viola-sonata-perf.gz -> ./data/viola-sonata-perf
>>      ./data/viola-sonata.gz -> ./data/viola-sonata
>>   * make velocity come from control functions so it can be randomized
>>     M ./data/bloom-perf.gz
>>     M ./data/pnovla-perf.gz
>>     M ./data/viola-sonata-perf.gz
>>   * make Derive.Call.Util.pitched_note only take pitch, not pitch and dynamic
>>     M ./data/viola-sonata-perf.gz
>>   * add Ui.StateConfig.Performance, which lets me save a "last known
>> good" performance with each score
>>     M ./data/bloom-perf.gz
>>     M ./data/pnovla-perf.gz
>>     M ./data/viola-sonata-perf.gz
>>   * update data/viola-sonata-perf.gz
>>     M ./data/viola-sonata-perf.gz
>>   * make Derive.with_instrument throw if the instrument doesn't exist
>>     M ./data/viola-sonata.gz
>>   * split generator and transformer calls
>>     M ./data/bloom-perf.gz
>>     M ./data/bloom.gz
>>     M ./data/viola-sonata-perf.gz
>>   * update regression tests, broken when I fixed midi channel allotment
>>     M ./data/bloom-perf.gz
>>     M ./data/pnovla-perf.gz
>>   * fix bug where midi events can be slightly out of order
>>     M ./data/bloom-perf.gz
>>     M ./data/pnovla-perf.gz
>>     M ./data/viola-sonata-perf.gz
>>   * update regression tests, and add viola-sonata
>>     M ./data/bloom-perf.gz
>>     A ./data/viola-sonata-perf.gz
>>     A ./data/viola-sonata.gz
>>   * add Derive.Regression_test
>>     A ./data/
>>     A ./data/README
>>     A ./data/bloom-perf.gz
>>     A ./data/bloom.gz
>>     A ./data/pnovla-perf.gz
>>     A ./data/pnovla.gz
>>   * import cleanups
>>     R ./Data/Map.hs
>>     R ./Data/
>>   * split Util.Data into Util.Array and Util.Map
>>   * expand InputKeys into InputNote with continuous pitch support,
>> working midi thru, add rdev and wdev state, don't pass chan map from
>> Cmd state
>>   * implement skeleton with Data.Graph instead of custom tree to make
>> toggle_edge easier to implement
>>   * implement background derivation
>>   * use locally hacked version of Data.Map that adds toDescList, this
>> is a temporary hack until my upstream patch goes in
>>     A ./Data/
>>     A ./Data/Map.hs
>>   * add Util.Debug.timer and nicer test formatting
>>   * clean up misc stuff in tests
>>   * implement Cmd.Simple loading, initial clipboard implementation
>>   * clean instrument names, warn about overlapping instruments, remove
>> PatchTemplate
>>   * implement Signal.equal
>>   * remove_events deletes 0 dur events
>>   * fix zero duration event bug
>>   * put instrument in the event, fix channelize bug, ReadMessage and
>> WriteMessage are real types
>>   * misc Util cleanups and additions
>>   * move Util.Array to more general Util.Data
>>
>>> What I would like to see is if we can somehow reliably recreate darcs being unhelpful with the case thing.  What is interesting is that if I understand correctly, it's not just the history because when do a get things seem to work for a while (which leads me by the way to suspect that things work for the "wrong" reason, and maybe with darcs get --no-cache you might find something weird and interesting)
>>
>> Indeed, this is what makes it tricky.  I've actually only had it come
>> back once so far, but it's probably mostly because I only very rarely
>> edit files in that directory.  Basically, at some point within the
>> last 6 months, I had the data Data problem, and figured out that I
>> could get a branch and it didn't have the problem.  So I deleted my
>> old main branch and moved the new working one to main.  Then recently
>> I went to edit files in data/ again and the problem had come back.  So
>> it takes something under 6 months worth of patches (more or less.. I
>> don't remember exactly which patch back there required the workaround)
>> to come back.  Possibly much less, but it's hard to know since I so
>> rarely modify files in data/.
>>
>>
>> BTW, this is surely unrelated, by why do all of the paths in --summary
>> start with ./?  Isn't that redundant?
>>
>> __________________________________
>> Darcs bug tracker <bugs@darcs.net>
>> <http://bugs.darcs.net/issue2356>
>> __________________________________
>> _______________________________________________
>> darcs-devel mailing list
>> darcs-devel@darcs.net
>> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>
>
>
> --
> Eric Kow <http://erickow.com>
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2356>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel



-- 
Sincerely yours,
-- Daniil

Thanks Dan! Evan, thanks again. I'm afraid we're going to have to just 
keep this in the tracker until we find out some means of reproducing the 
error. Please do shout when it happens again, if nothing else to remind 
us about the issue.

I did a BTS search, don't think anything of interest is in there :-/

http://bugs.darcs.net/issue?
%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignedto%2Cstatus&%40sort
=activity&%40group=priority&%40search_text=&%40action=search&title=insen
sitive&submit=Search+issue+titles