What should I check in/not check in? Since many of the files are sometimes auto-generated I'm not entirely sure how to handle this using version control...does it have something to do with tags?
For instance in ANT, I know not to check-in my target/bin directories...but Grails adds another level of confusion to this...since some of code is generated and some of it is not.
(It may become clearer as I go...but it seems to be that there needs to be some way of being able to tell what was just generated and what was modified by a developer so that it needs to be placed in version control)
Here's the .hgignore directory I've got on my most recent grails project (with a couple of project specific things taken out):
syntax: glob
out
target
logs
*.iml
.idea
*.iws
*.war
workspace.xml
lib/build
lib/compile
lib/runtime
lib/test
~$*
stacktrace.log
*.tmproj
*.launch
reports/
*.orig
*.zip
.DS_Store
*/.DS_Store
web-app/WEB-INF/classes
cobertura.ser
The generated code in Grails should be placed under version control. It's not secondary executable code that is generated by the build process like class files, but instead is code that is part of your source. The generated code is intended to be just a starting point for your application and will most likely be modified at some point anyway.
Also check this:
http://www.grails.org/Checking+Projects+into+SVN
and this:
https://stackoverflow.com/questions/4201578
Related
Due to the fact that we need to integrate the Zend Framework on our project root, and that generating that documentation will be useless and take long time, I would like to generate documentation for all files inside application folder only.
Does anyone know how I can generate documentation for a specific project folder, trough Netbeans 7.0 interface?
Update:
The best I've found so far was to:
Open the terminal window from netbeans, and type:
sudo phpdoc -d public_html/yoursite.dev/application/ -t public_html/yoursite.dev/docs/
Update 2
Let's suppose our Zend library is inside projectrootname/library/Zend we also can try, by going to: Tools > Options > Php > PhpDoc and place the following:
/usr/bin/phpdoc -i library/Zend/ -o HTML:frames:earthli
At least for me, that doesn't seem to work, because, when I try to generate the documentation, I get permission error issues displayed on the output window.
Thanks
The -d/--directory option [1] should be used to highlight the most high-level code directory that you want phpDocumentor to start reading from. If your Zend folder is at or above the level of your application directory, then just using --directory /path/to/application should help you document only your application code.
If your Zend folder is somewhere inside your application (e.g. in your app's ./lib folder), then you can use the -i/--ignore option [2] to tell phpDocumentor about any directories that it will see but should ignore, --ignore *zend*. Just be aware that formatting your ignore value can be tricky, so see the examples in the manual. Also, be aware that as phpDocumentor runs, you will see these ignored folders and files being listed in the output... phpDocumentor "ignores" them by not generating docs for those files. It does, however, still need to parse them, in case those objects are referenced in files that do get documented.
[1] -- http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#using.command-line.directory
[2] -- http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#using.command-line.ignore
I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.
I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.
The only options I've thought of so far are:
Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.
Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.
The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.
Is there a better/recommended way to deal with this?
As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:
./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>
(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.
We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.
I have a problem with my development workflow and Sphinx. I want to keep configuration file for Sphinx in version control so it's easier to manage. This means it's easier to link the file to code updates, etc ... However, the configuration file is stored in /usr/local/etc.
There are two solutions I can think of. Store the file in the repository and move it to the correct folder on deployment or recompile Sphinx to look for the file in my repository. I had a suggestion from someone to use a symlink, but that still requires a change on deployment.
Is there an elegant solution in Sphinx I'm missing?
perhaps have the /usr/local/etc/sphinx.conf file be a script that pulls the actual sphinx config from the file in your repo.
http://sphinxsearch.com/docs/current.html#rel098 scroll down to general and you'll see:
"added scripting (shebang syntax) support to config files (example: #!/usr/bin/php in the first line)"
Problem: Using genstrings to create Localizable.strings files from a project. A few weeks later, some things changed and I run genstrings again. 75% of the new file is already in the old file. How could I merge the new file with the old file, so that the old file contains all of those 25% new key-value-pairs?
I recommend Localizable Strings Merge too. I use it on my projects and it really a simple to use and powerful software.
I just found the Localization Suite. Incredible powerful tool for free. I tried it on my project and it just works. Lacks documentation though.
I use a script to run genstrings with existing translations merged automatically when I build a project. Updated strings are detected by git or another source control you use. The script supports storyboard and xib localization too.
To run the script automatically, put the script into your project root directory, and add a Run Script phase with the following line to a target build phases in your project settings.
./mergegenstrings.py PathToSourceDir
My script is based on the script in this post. I modified it to support Swift and to add the arguments.
What about 3rd party applications like BBEdit? After all Localizable.strings file is a text file. BBEdit has a find differences feature and you can merge from old to new or opposite.
If you install XCode, there is also a standard application installed to merge files called FileMerge.app, you can find it in /Developer/Applications/FileMerge.app
I'm not sure but ReSharper may help you. teake a look at it.
I have my VCS set up to ignore "[project]/bin". Is this directory essential to restore a project, or can it safely be ignored?
The "bin" directory can be safely ignored. MonoDevelop will create it when building the project.
If MonoDevelop recreates the bin directory when you delete it, then this is simply a matter of taste, otherwise you have to leave it in. (Rails happens to give up if you delete its logs).
Putting empty directories under version control can make the build process more readily apparent to those who glance at the repository, but it can also clutter and distract if you'd rather see only the essentials.