FireBreath nightly build ships with .svn source control data in the gecko header files

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download the nightly build
2. Unpack it
3. Check it into a svn server

I expected to be able to check in the code so we could track changes as we 
developed our plugin. The .svn file in the gecko-sdk header directory caused 
some problems.

I downloaded the firebreath 1.1, nightly build 21. Operating system is Windows 
in this case, but I've seen it happen in Linux as well.

This isn't a big issue, removing the svn file addressed the issue but it seems 
like it shouldn't be there. Other than that, this is an incredible project and 
a real service to the open source community. Thanks!

Original issue reported on code.google.com by gearoid....@gmail.com on 12 Aug 2010 at 11:07

[GoogleCodeExporter]

The reason we have left those there is that there should be no reason you need 
to check in the entire tree to another source control, and having them there 
makes it very easy to update the npapi headers over time.

Anyone else have a preference on how this should work?

Original comment by taxilian on 12 Aug 2010 at 1:40

[GoogleCodeExporter]

I ran into this problem too. Obviously not a huge deal.

How are we to share a FireBreath prject with others if not via source control? 
Especially those of us who have had to make changes to cmake files and/or 
FireBreath code itself...

Original comment by richcata...@gmail.com on 12 Aug 2010 at 2:51

[GoogleCodeExporter]

well, my recommendation has always been to keep your firebreath changes in a hg 
clone on google code.  Of course, I'm hoping you'll contribute those changes 
back to the community =]

I keep firebreath seperate from my projects and put my projects in one source 
control, keep firebreath itself in another.  That keeps me honest with the 
abstraction.

Maybe we could write a script to remove the .svn dirs or something; or if you 
write one, we could put it in the repo =]

Original comment by taxilian on 12 Aug 2010 at 3:13

[GoogleCodeExporter]

I suspect I'm not the only one whose source control practices are dictated by 
their employer =/.

My changes probably aren't very interesting. They're basically there to allow 
me to use ObjC++ on the Mac (fake Cocoa support, just what is needed for 
Foundation).

Original comment by richcata...@gmail.com on 12 Aug 2010 at 3:19

[GoogleCodeExporter]

I'm going to leave this as-is for now; we will revisit it if more people 
complain.

Sorry :-/

Original comment by taxilian on 13 Aug 2010 at 10:48

• Changed state: WontFix