[darcs-users] boringfile and binary problem

Josh Hoyt josh at janrain.com
Thu Sep 15 22:35:45 UTC 2005


Tommy Pettersson wrote:

>On Tue, Apr 19, 2005 at 12:52:24PM -0700, Josh Hoyt wrote:
>  
>
>>Hello,
>>
>>I have a repository with a Python project in it. I end up with .pyc 
>>files that should be ignored according to _darcs/prefs/boring. I am 
>>using the default boring and binaries files. I have attached the output 
>>of darcs --exact-version.
>>
>>When I run darcs whatsnew, I get a lot of:
>>
>>{
>>binary ./__init__.pyc
>>...
>>binary ./rpc.pyc
>>binary ./util.pyc
>>}
>>
>>These files have never been added to the repository and the patch does 
>>not have addfile lines for these files. Does the binary line implicitly 
>>mean addfile? Either way, shouldn't these files not be included in the 
>>patch because they are boring? (\.py[co]$ being the operative line of 
>>_darcs/prefs/boring)
>>    
>>
>
>The binary means the same as hunk but for binary files, so
>it means the .pyc files do have been added to the repo at
>some time and now have unrecorded changes.  Search in the
>output from 'darcs changes -s' after 'addfile.*pyc' to see
>what patch did add them.  If you can't find any addfile then
>look for 'move.*pyc' in case some .py file have accidently
>been renamed to .pyc with a 'darcs move' command.  The move
>doesn't check the new file name against the boring patterns.
>
>It should not be possible to add boring files without the
>--boring option.  Test if you can 'darcs add foo.pyc' without
>getting the "Skipping boring file foo.pyc" message.  If so,
>there might be a --boring option in either ~/.darcs/defaults
>or _darcs/prefs/defaults, or the boring file might have been
>changed with 'darcs setpref' in which case you should have
>a setpref patch in the output from 'darcs changes -s'.
>
>Otherwise you might have found a bug.
>
After dusting the cobwebs off of this issue, I have discovered the problem:

We have a script that generates .pyc files from .py files. We ran it on 
the root of the repository, which also compiled the .py files in 
_darcs/current! The script compiled those files before it compiled the 
working directory, so the .pyc files in the working copy had newer 
timestamps. When the files were examined, darcs saw that they are binary 
and so created the binary patches.

In short, the moral of the story is that one must always be careful 
about running programs that may affect the _darcs directory, especially 
the pristine copy.

--
Josh Hoyt <josh at janrain.com>




More information about the darcs-users mailing list