The situation: you wake up one morning and update your flash builder project, only to get an error message saying there is a conflict in .actionScriptProperties. Images of the rap video Who Broke the Build suddenly rise up out of you memory…before you throw that keyboard through that nice 30″ Cinema display, take a deep breath and read on. It’s not as bad as you think. In fact, you could have prevented this from happening in the first place, but now that it’s happened, you can fix it so it doesn’t happen again.
Assumptions / Background:
-you’re using Subversion (SVN) for version control
-you’re using Flash Builder (same applies for Flex Builder, but this tutorial is specific to Flash Builder) with the Subclipse plugin
Sometimes you want to tell svn not to update or commit certain files in your local project, such as .project, so you don’t have to remember not to check them in when you do a check-in at root level. You could try telling your team to just not check those files in, but not only is that a pain to remember to do, but most likely in the end they will wind up getting checked in, anyway. The common solution to this is to use svn:ignore, which tells svn to ignore those files and not check them in. To get to that option normally would be easy – just right-click on the file or directory in Flash Builder and choose Team->Add to svn:ignore. However, most likely if you are trying to ignore files or directories that start with a dot ‘.’ then you aren’t seeing them in Flash Builder at all, are you? The dot is the naming syntax for hidden files in unix/linux, and Flash Builder / Eclipse respects this. OK, so to see the files within Flash Builder, first of all, switch from the Package Explorer (new to Flash Builder) to the Navigator (more like what we were used to in Flex 3 and prior):
Navigate to Window->Other Views and then select the Navigator. Now you should see your project by the file structure rather than package structure. Next, select the drop down menu from within the Navigator and choose Filters, and uncheck whatever types of files you want to see.
OK, so now you see the file you want to ignore…but if the file was already added to svn, that option to svn:ignore it is grayed out.
When a file has been added to svn already, the option to ignore it is disabled
Now what? This part is a little more tricky (I found the solution for this next part here):
1. Delete the file from the repository (make a backup first!)
2. Recreate it in Eclipse
3. Set svn:ignore on it via Team->Add to svn:ignore
Hopefully now you’re good to go, and your Flex team is still alive and breathing! 
As of FB4 we started rechecking in all DOT files again. FB4 makes very smart use of workspace variables so it hasn’t been storing any absolute path related details in any of the dot files. In our case all other options like compiler arguments etc are exactly the same for all devs. Ant takes case of some RSL specific differences and we use flex project files as source for the ‘includes’
IN a nutshell, its ok to checkin all DOT files!!!
@tntomek that sound’s great in theory, but unfortunately this blog post was inspired by an actual incident that happened just this morning – and our build was indeed broken, in Flash Builder, because someone checked in the .actionScriptProperties file. Flash Builder may be smarter about the dot files than earlier versions, but it still isn’t perfect, and I still wouldn’t let my dev’s check that stuff into svn.
Furthermore, not every dev’s project is going to be the same. For example, some dev’s might be actively editing a library project that the main project is linked to, while other developers who aren’t working to edit that library project, use a .swc file in the libs folder, instead. In cases like these the project properties are bound to differ.
I agree that the non-relative paths in the past has been a huge pain, especially when we had teams where the environments were mixed, with some folks on Windows and others on Mac.
It’s good the process works for you, we found that having the exact files devs work on vs maintain a separate file for build server far outweighs the accidental checkins scenario. Why would your developers make SWC references vs having a closed project open in Flex builder? that will correctly toggle SWC vs code usage.
In fact with FB4 being so x-platform friendly I’m planning to rebuild our ANT process to just scrub the ‘include’ classes and assets directly from the DOT files (there was a good blog post on this a few month ago). Project references in build script are still separately maintained for build server.