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

26 lines
276 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
Copy permalink