I'm using git to track a project I'm developing in Flash Builder, and I'm wondering the best way to go about having it track it, especially regarding Flash Builder generated files, Compiler generated files, and source files that aren't necessarily flex files.
I had it set up to ignore all of the flash builder .project & debugging directories via .gitignore:
.actionScriptProperties
.flexProperties
.metadata
.project
.settings
bin-debug
and also treating any swf/swc files as binaries via .gitattributes
*.swf -crlf -diff -merge
*.swc -crlf -diff -merge
One issue with this setup is checking out this project and using
it in Flash Builder from scratch:
Flash Builder doesn't like it when
you have a project folder without
the .project files. Only way to
import the source into Flash Builder is to:
Create a new Flex Application
Smother the template files it
created (specifially APP_NAME.mxml)
with a git clone.
Where do I put libraries? From a git perspective, I'd like to have them in the lib folder of the repo so when someone clones the repo, everything just works, but from a local file system perspective I'd like to store all my libraries in a single location and use Flash Builder to reference them, as I may update the library or download a later version. Maybe I should put the libraries in their own repo and load them as a git module? This way I don't need to manually remember to update my Y library files in all X projects that are using them, edit: they will simply update when I update each projects' submodules.
And what about external swfs/flex modules? I've was sticking external swf files in the bin-debug folder for now so the SWFLoader class can find them, but because I'm .gitignoring the bin-debug folder, they don't come with the repo when it's cloned.
One final issue is where to keep the files for the server. Do I have them in a separate repo? I'm using php VOs' with AMFPHP so it's good to be able to edit the php files alongside my actionscript files in Flash Builder... but they don't belong in the project src folder.
The current solution I'm using is:
Creating a 'server' folder in the project root
Pointing an apache virtualhost at it
Setting the run/debug settings to http://APP_NAME.localhost
Then using the server folder as a replacement for bin-debug when the files get exported
The problem with this is I've got a big mess of compiler generated files, and non-AS source files in my server folder. It just doesn't seem like an elegant solution.
How do you set up git to work with flash builder smoothly? Could all this be resolved with multiple git repos/Flash Builder projects, or an ANT script or something?
Thanks.
I've found a good solution which avoids all of the horror of having untracked files and keeping a massive .ignore list:
CLEAN your projects before you git commit.
Simple as that.
Whether it be by Flash Builder or by ant, you should have the ability to clean anyway, so if you simply clean before you commit, the problem of generated files is solved. Duh.
In fact you could probably set it up as a git hook or something.
Typically for eclipse projects with any SCM, I initially check in everything including .projects, etc., but maybe except bin-debug in your case. Then just make sure that anybody who checks out the project never checks back in those .xxx files. For instance, when I use perforce, I first check out the .xxx files to a changelist that I never check in. Then check out the rest to a separate changelist.
Another tip is to use user defined library variables when working with build paths, etc.
Related
I believe this question applies to CMSes in general.
I'm using a CMS, Kentico, for a particular web application. The CMS installer generates its own boilerplate project with 10,000+ files, and this project amounts to a runnable web app. Very few of the CMS-provided files are intended for modification. Yet standard practice is to add custom code to the project, and to check the entire project into source control.
I dislike the idea of checking in my entire CMS. I prefer my repository to contain only the code particular to the project, while vendor files are automatically "pulled in" from elsewhere. For example, Visual Studio can restore NuGet packages into a fixed location in the project, and this location can be ignored by version control.
In a way, development with the CMS is dirtier than when using a typical vendor library. Usually your own code depends on a library, while the library is independent from your code. However, the CMS wants to be your app, and your own code interweaves. The CMS requires customization of its own provided files. You can't just "pull in" the CMS files to a fixed location and then ignore that location.
Given this scenario, I'd still like to omit as many of the CMS files as possible. So far, I've settled on this strategy:
Keep a pristine, readonly copy of the CMS-provided files at a standard, local path.
Create a fresh project root directory.
Copy the CMS-provided project file to the project root.
In the copied project file, change the 10,000+ file paths to point to those pristine CMS files, which are external to the project root.
Place only files with custom code into the project root. If a CMS-provided file must be modified, copy it into the project root directory and use that copy.
This strategy sounds good in theory, but it's more complicated in practice. Here are a couple complications:
Changing 10,000+ file paths to "link" in external files turns out to be more than a find-replace operation. More complex mapping is necessary to preserve the pristine project's directory structure.
The web server requires all the files to be in the same directory. Using the project file to link in external files is fine for compilation, but you've split your web root in two.
For the latter problem, it seems the best workaround is to perform post-build copy operations. This is, in itself, more complex than it seems from the outset.
As I write this, I'm starting to feel like I should go ahead and just dump the entire working CMS into my repository. It feels dirty, but it's a hell of a lot simpler. Before I do that, does anyone have any experience or ideas for how I might accomplish my goal?
To restate my question: How can I exclude my CMS's provided files from my version control repository, while still including them both in my project / build script and in my web app root?
Here's another idea for how to accomplish this:
I establish a standard local directory for Kentico DLLs and the Kentico installer, which will not be in version control.
I create KenticoSupport.csproj, a class library of types extending built-in Kentico types, just as they are intended to be extended. This will also contain content, such as JS, CSS, ASPX, ASCX, etc. files. This will be in version control, but it references the central Kentico DLLs, which are not in version control.
I create KenticoBuilder.csproj, a mostly empty project that is mainly a build script. It also contains a few simple *.patch files to modify matching Kentico files, such as Web.config and Global.asax.cs. This is under version control.
Here's what the KenticoBuilder.csproj script does:
Build KenticoSupport.csproj.
Create an output directory that will serve as both a web root and a project directory.
Install / copy the pristine Kentico project files into the output directory.
Apply patches to matching Kentico files in the output directory (mainly to add config lines and custom bootstrapping).
Copy custom DLLs and content from KenticoSupport to matching locations in the output directory.
Build the project at the output directory.
It's complex, but I think it might just work. Thoughts, anyone?
Kentico should hopefully be fixing this soon, with pre-built dlls you can reference rather than rebuilding the entire CMS every time you modify C#.
Until then, have you considered using a Symbolic Links to reference your pristine files? Then just overriding the links with your modified files when need be?
See this other question if you haven't used them before. mklink comes with newer Windows versions (Command-line), but there are a bunch of third party GUI based apps as well.
I came up with an ideal strategy:
Place the pristine CMS files at an external "code libraries" location, and make them read-only for good measure.
Make a copy of the CMS-supplied project file.
Convert all project items to link to the code library's copy, including assembly references. The required link element for MSBuild complicates this, so I wrote a little console app to parse the XML and generate the necessary elements. I also store the path to the library in a property.
At this point, you have a compilable project. The files are all just links to read-only, baseline, CMS-provided files, but the IDE shows a nice directory structure, as if the files were actually in your repository. As you customize, you can replace the links with your own actual files.
However, your website files are now split between two completely different locations. The web server needs them to actually be in the same directory. This is where some scripting comes in handy.
Using your build scripting tool, plug into the post-build event to copy linked files into the project directory. Naturally, you can omit the compiled files. Here's how I did it with MSBuild (thanks to this blog post):
<Target Name="AfterBuild">
<ItemGroup>
<LinkedKenticoFiles Include="#(None);#(EmbeddedResource);#(Content)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(MY_LIBRARY_BASE_PATH)'))" />
</ItemGroup>
<Copy SourceFiles="%(LinkedKenticoFiles.Identity)"
DestinationFiles="%(LinkedKenticoFiles.Link)"
SkipUnchangedFiles='true' />
</Target>
Optionally, plug into the cleaning event to remove those files. I used similar MSBuild syntax to delete the files, and because it leaves behind empty directories, I remove empty directories, too. (Thanks to this answer.)
<Target Name="BeforeClean">
<ItemGroup>
<LinkedKenticoFiles Include="#(None);#(EmbeddedResource);#(Content)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(MY_LIBRARY_BASE_PATH)'))" />
</ItemGroup>
<Delete Files="%(LinkedKenticoFiles.Link)" />
<ItemGroup>
<Directories Include="$([System.IO.Directory]::GetDirectories($(MSBuildProjectDirectory), '*', System.IO.SearchOption.AllDirectories))" />
<Directories>
<Files>$([System.IO.Directory]::GetFiles("%(Directories.Identity)", "*", System.IO.SearchOption.AllDirectories).get_Length())</Files>
</Directories>
</ItemGroup>
<RemoveDir Directories="#(Directories)" Condition="%(Files)=='0'" />
</Target>
Optionally, make your source control ignore the site / project folder, to avoid checking in the temporary, copied site files.
I've got a Flex 3 project. It works fine. But, I'd like to make some major changes to it.
Is there a way to duplicate the project and work on the copy? It's critical that I don't screw-up the original. But, I'd like to make major changes to the copy.
I tried making a copy of the project and renaming it. But, when I try to import the copy into Flex Builder, it says: "A project with the same name already exists in your workspace. Rename or delete the existing project." -- even though I renamed the project file and the main mxml file.
Unfortunately, I don't have a subversion program set-up, and I think that it will be a hassle to do so. Is there an easy way to work on a copy of a project?
My project uses a mySQL database. I don't know if that makes any difference.
Thank you.
-Laxmidi
First thing first. You need to have a version management, if you are doing branching and merging. Creating local subversion repo is not that big a deal, but I use local git repository and it takes a minute to initialize a repository.(local)
Now on to your question. You can create a copy of your project and the reason why your IDE is complaining is you have copied the project folders also ( project folders like .classpath and .project generated by your IDE). To make a copy, create a new project in your IDE and just copy the src folder ( and other versioned files ). You should be fine then.
Background: Trying to set up my dev. environment in new job. Have subversion installed ok in Flash Builder 4, and checked out the project folders I will be working on. Work to date was developed in FB3, I'm going to be using FB4.
The folders/files that get imported to the project also include .flexProperties, .actionScriptProperties, .project, html-template etc (basically everything).
I would have thought that just the src, libs, lib-rsl etc should be part of the svn?
UPDATE:
Here is a good link to setup details for sharing svn flex projects using 2 folders, one of which has the checkout code, the other of which has folders linked to the first (but without the project/setup files)
It depends on the the development group. If everyone is provided the exact same set of tools in the exact same environments it can be ok to include the IDE project files. But if there is any chance that anyone is going to use a different environment (this includes a rolling upgrade of tools) then it is a bad idea. I recommend against putting these files in source control.
When setting up a source control repository for a Flex Builder workspace, what do you consider to be worth checking in? Do you exclude the workspace .metadata folder but keep the .project and other project specific files? Keep both? Throw away both? Is there a guideline you use to decide which is worth holding onto or do you do it out of practical experience?
We check in the source files but not the binaries or settings files (e.g., .actionScriptProperties, .flexLibProperties, nothing in bin-debug, nothing in target directory). We build and deploy with Maven.
I check in the source directoy and the binary directory; nothing else. I set up my Flex Builder project to use a linked directory as my primary source; which keeps the code and repository independent of any project specific settings.
I have known people who check in all the project files. This makes it relatively easy to check out and then set up a new project; as you can import the project folder very easily into Flex Builder.
I can't say one is better than the other, though. It depends what you want to do.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.