BinaryBuilder & SVN

#1

I just started tracking my project in SVN (unfuddle, which is cool). But binary builder seems to pick up the invisible files:

Adding bars_gif: 2722 bytes Adding blank_devices_xml: 10684 bytes Adding blank_source_svg: 7215 bytes Adding default_data_xml: 12332 bytes Adding icons_zip: 85904 bytes Adding sources_zip: 228663 bytes Adding splash_image_jpg: 114598 bytes Adding vc_icon_png: 4489 bytes Adding allwcprops: 918 bytes Adding entries: 1728 bytes Adding format: 2 bytes Adding bars_gif_svnbase: 53 bytes Adding icons_zip_svnbase: 53 bytes Adding sources_zip_svnbase: 53 bytes Adding splash_image_jpg_svnbase: 53 bytes Adding vc_icon_png_svnbase: 53 bytes Adding bars_gif_svnbase: 2722 bytes Adding blank_devices_xml_svnbase: 10684 bytes Adding blank_source_svg_svnbase: 7215 bytes Adding default_data_xml_svnbase: 13919 bytes Adding icons_zip_svnbase: 85904 bytes Adding sources_zip_svnbase: 228663 bytes Adding splash_image_jpg_svnbase: 114598 bytes Adding vc_icon_png_svnbase: 4489 bytes
Sadly, they seem to be as big as the actual files. They’re hidden in the OS X GUI so it would be awkward to move them each time. Could BinaryBuilder see if they’re hidden somehow?

Thanks,

Bruce

#2

OK, on Mac, if I change the BB wildcard to . it’s OK for me. Would that mess up existing behaviour? I couldn’t find a way to wildcard for a compulsory character before a .

BTW, I did see that the stuff in folders was ifdef’ed out, but the files sizes would be a problem, especially as subversion started doubling the things that were only doubled because of it etc. I’m sure there’s some way to get an infinite size loop going.

Bruce

#3

Oops. Spoke too soon. It did still get the files inside the hidden directories. So I just turned off the recursion. I know Binary Builder is an ‘as is’ product, but it seems like a reasonable request for Mac - in fact, I’d probably rephrase the request as the Mac version of findChildFiles ignoring hidden files by default. Sorry I can’t suggest the code fix, I haven’t even looked at the file class before, and it’s a bit of a mystery to me (you can take that as a testament to the docFile classes if you want ; )

Bruce

#4

Well I don’t think I’d want to make findChildFiles ignore hidden files, as I’m sure there are lots of good reasons for finding hidden files.

Perhaps a better tweak to BB would be to just add a line that ignores files beginning with a dot, rather than changing the wildcard?

But BB is there for people to mess with, and I’d suggest just hacking it yourself in whatever way works best.

#5

Ok, thanks. I think I’ll go with my BB bodge then. With no recursion, and only files that have a prefix, dot and postfix, it does what I want.

On the hidden files thing, what about an extra param to ignore hidden files? If it defaults to false then existing behaviour should be OK, shouldn’t it? The reason I mention is - well consider this:

folder

  • file 1.a
  • file 2.b
  • file 3.c
  • others/
    • file 4.c
  • ./
    • not this one.really

There’s no way to wild card out files within hidden folders (AFAIK), so they would be returned in counts etc. Since Joe user can’t even see them, it seems unlikely he would want them.

Otherwise, on Mac (and probably Linux), all the file find functions might have to be replaced, case by case. Of course, I’m most worried about a user having some strange hidden files that I haven’t anticipated - my tests would all be fine, then something could gang agley at their end.

Bruce

#6

well yes, I suppose as an option it could be handy…

#7

For a compulsory character before a dot in a wildcard, would this not work? “?.” (between the quotes)

#8

Could be - believe it or not I couldn’t find info on wildcard parameters.

But it wouldn’t help with the recursion we discussed - the code, as is, will still find well named files in hidden folders.

Thanks,

Bruce

#9