Skip to content
Browse files

Project files (`.project`, `.actionScriptProperties` and `.flexProper…

…ties`) removed from .gitignore as they should be version-controlled.
  • Loading branch information...
1 parent 4b6bf65 commit 818ed295cf3f68e77e003f8a1f101074f6bddca6 @borekb borekb committed Jun 26, 2012
Showing with 5 additions and 4 deletions.
  1. +5 −4 Actionscript.gitignore
View
9 Actionscript.gitignore
@@ -3,8 +3,9 @@ bin/
bin-debug/
bin-release/
-# Project property files
-.actionScriptProperties
-.flexProperties
+# Other files and folders
.settings/
-.project
+
+# Project files, i.e. `.project`, `.actionScriptProperties` and `.flexProperties`
+# should NOT be excluded as they contain compiler settings and other important
+# information for Eclipse / Flash Builder.

6 comments on commit 818ed29

@pmowrer

.project, .actionScriptProperties and .flexProperties should absolutely be included. They contain many environment-specific settings and aren't portable. Settings and "important information" should be abstracted out into the build process.

@borekb
borekb commented on 818ed29 Nov 10, 2012

F11 is the build process for many many Flex applications. Those 3 project files do not contain environment-specific things (if you think they do, please point them out) and are portable.

@pmowrer

There is a propensity for .actionScriptProperties and .project to contain absolute paths. For example, a SWF project's outputFolderLocation in .actionScriptProperties is often a path to a local server.

Maybe more crucially, in a team environment these files will be committed constantly because of differences in members' environments or small local changes that someone commits by mistake.

I believe its better practice to leave them out . It forces you to think about and document your project's dependencies and settings, perhaps through a flex-config.xml or a build system (GradleFx has an awesome auto-generation feature for these files).

@borekb
borekb commented on 818ed29 Nov 10, 2012

in a team environment these files will be committed constantly because of differences in members' environments or small local changes

Sorry but that is just not true. On a project with about 10 developers and hundreds of commits every day, changes to Flash Builder project files only happen once every few days or weeks, and every time it's for a good reason. Eclipse / FB doesn't store developer-specific things in these files and if you look at some real-world examples, it is also not true that most paths are absolute. In my typical .actionScriptProperties file, attributes like outputFolderPath, sourceFolderPath, libraryPathEntry.path, excludedEntries.path, they are all relative.

I'm not saying that there aren't projects that contain some problematic things in these files and in that case, they should probably use some other process to specify dependencies and generating FB project files on demand. But for a Flex project that starts from scratch and probably doesn't have a sophisticated build / project file generation process from day one, Eclipse project files should typically be version controlled.

@pmowrer

it is also not true that most paths are absolute.

Your words, not mine.

I'm not saying that there aren't projects that contain some problematic things in these files

Those 3 project files do not contain environment-specific things

Which is it?

Even the Apache Flex SDK team is experiencing the problem of mistaken commits of these files (where you'll find both points argued).

We'll agree to disagree. I understand where you're coming from and I know a lot of Flex developers do commit these files to source control, but I continue to believe it's best practice not to commit them. In the end, it probably shouldn't be put in such absoute terms ("should NOT be excluded") nor the inverse, which I'm guilty of.

@borekb
borekb commented on 818ed29 Nov 12, 2012

Which is it?

You pointed out some example with outputFolderLocation which would be problematic if it's a local path - I don't know, I don't have such attribute in any of my .actionScriptProperties files but if you do and the value is developer-specific, then it would be a problem. However, on any project I have participated on, there has never been a problem with version-controlling these files.

You're right and I fully agree, though, that the comment in the current gitignore probably shouldn't be stated as prescriptively (SHOULD NOT etc.). Feel free to update it.

Please sign in to comment.
Something went wrong with that request. Please try again.