revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2025-03-04 00:19:18 +01:00
Code Issues Releases Wiki Activity
phorge-phorge/.gitignore

33 lines
409 B
Text
Raw Normal View History

Import some code, some of which may be relevant to the project.
2011-01-16 13:51:39 -08:00
.DS_Store
._*
Allow specifying custom celerity resource map Summary: We have custom static resources. We currently include them in Phabricator's celerity resource map which is causing some pain - we need to regenerate the file without our custom resources before pushing upstream, we need to discard our changes before pulling from upstream and we need to rebuild with our changes to run Phabricator. This diff allows writing and reading the map in other location. The plan is this - I will run `celerity_mapper.php` twice - once to build Phabricator-only resources (to push to upstream) and once to build Phabricator + ours resoruces to put in our directory. Better solution would be to create a map just with our resources and read and combine it with Phabricator resources. But it is complicated because we have dependencies on Phabricator resources. Test Plan: `celerity_mapper.php webroot` `celerity_mapper.php webroot ../facebook/src/__celerity_resource_map__.php` Delete Phabricator's celerity map, set 'celerity.resource-path' and successfully load Phabricator. Reviewers: epriestley, edward Reviewed By: epriestley CC: aran, Koolvin Maniphest Tasks: T721 Differential Revision: https://secure.phabricator.com/D2630
2012-05-31 16:04:10 -07:00
/webroot/rsrc/custom
Gitignore additions Summary: Make sure emacs and vim swap files don't get added. Test Plan: Try to add them, and watch them not get added. Reviewers: epriestley CC: Differential Revision: 427
2011-06-10 12:54:01 -04:00
.#*
*#
*~
*.swp
Key Value Store for ManiphestTask Test Plan: Look at a task detail. Some dummy attributes are automatically added in ManiphestTaskDetailController. Reviewed By: epriestley Differential Revision: 730
2011-07-25 17:34:56 -05:00
# NetBeans project files
Fix whitespace
2012-04-06 01:00:32 -07:00
/nbproject/
Rough batch editor for Maniphest Summary: First stab at a batch editor for Maniphest. Basically, you can select a group of tasks and then import them into the "batch" interface, where you can edit all of them at once. High level goal is to make it easier for users in PM/filer/support/QA roles to deal with large numbers of tasks quickly. This implementation has a few major limitations: - The only available actions are "add projects" and "remove projects". - There is no review / undo / log stuff. - All the changes are applied in-process, which may not scale terribly well. However, the immediate need is just around projects and this seemed like a reasonable place to draw the line for a minimal useful version of the tool. Test Plan: Used batch editor to add and remove projects from groups of tasks. Reviewers: btrahan, yairlivne Reviewed By: btrahan CC: aran, epriestley, sandra Maniphest Tasks: T441 Differential Revision: https://secure.phabricator.com/D1680
2012-02-24 13:00:48 -08:00
# Arcanist scratch directory
/.arc
Add a local configuration source and a non-environmental ENV config source Summary: See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password). Some options for this are: - Have them live in ENV variables. - These are often somewhat unfamiliar to users. - Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV. - Some environments have limited ability to set ENV vars. - SSH is also a pain. - Have them live in a normal config file. - This probably isn't really too awful, but: - Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty. - So they have to copy or create a file, then edit it. - The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y". - Have them live in an abnormal config file with script access (this diff). - I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file. I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users. This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars. Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`. Reviewers: btrahan, vrana, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 06:16:15 -08:00
# Diviner
/docs/
/.divinercache
# libphutil
/src/.phutil_module_cache
# Configuration
/conf/custom/*
/conf/local/local.json
/conf/local/ENVIRONMENT
Remove PhabricatorSetup and make PHABRICATOR_ENV optional Summary: - PHABRICATOR_ENV is now optional. If you don't specify it, we won't load a config file. - PhabricatorSetup is now gone. - I removed the alternate file domain check for now, see T2380. - `phabricator.setup` config is now gone. - Rewrote documentation: - No more mentions of `phabricator.setup`. - Normal install guide no longer mentions PHABRICATOR_ENV. This is now an advanced topic. - Clarified that you only need to set up one of apache, nginx or lighttpd. - Tweaked a few things I've seen users have difficulty with. This should have no effect on any existing installs, but make the process much simpler for future installs. Closes T2221. Closes T2223. Closes T2228. Test Plan: - Removed my PHABRICATOR_ENV and went through the install process. - Generated and read documentation. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2221, T2223, T2228 Differential Revision: https://secure.phabricator.com/D4596
2013-01-23 12:03:19 -08:00
/conf/local/VERSION
Impact Font Used If Available Summary: Fixed T2395 Test Plan: When impact.ttf was added to resources/font, it was being used. When renamed, tuffy was. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2395 Differential Revision: https://secure.phabricator.com/D4700
2013-02-01 08:19:33 -08:00
# Impact Font
/resources/font/impact.ttf
Add a user-accessible hook for dumping debug code into an install Summary: Currently, there's no easy way for me to tell a user "run this code from the webserver and tell me what it says". Sometimes installs can add new .php files to, e.g., `webroot/rsrc/`, but this is setup-dependent and not universal. Generally I resort to saying "put this into index.php", but that's error prone and not acceptable on active installs. Add a "debug" controller so I can instead say "put this into support/debug.php, then visit /debug/". Test Plan: Visited /debug/ with and without support/debug.php files. Visited /staus/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5212
2013-03-04 13:45:51 -08:00
# User-accessible hook for adhoc debugging scripts
/support/debug.php
Copy permalink