Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
Original issue reported on code.google.com by
gearoid....@gmail.com
on 12 Aug 2010 at 11:07