rfay

; Configuration for xdebug; the main file is xdebug.ini
xdebug.remote_enable=1

xdebug.remote_host=10.0.2.2
; xdebug.remote_port=9000
; you can comment the next line once Xdebug is working
xdebug.remote_log=/tmp/xdebug.log

rfay

$("body").css('background-color', 'blue');

rfay

1. The watchdog() in the user_block_user was using $user without initializing.

2. The bug I'm actually working on (inability to assign).

rfay

Sandboxes can be used for many things, and one of the things they will be used for is for teams collaborating on larger projects, or adding large features to existing modules, etc.

In that situation we have a couple of new complexities:

• We (possibly) have multiple collaborators who can commit.
• If this is a feature of an existing project we will occasionally have to sync it up with that project so we don't have a massive soul-crushing merge when the time comes to do so.

This is one possible workflow for this situation:

1. Create a new sandbox on drupal.org. Mine will be named my_views_feature, and it will be a new feature for the views project. The commmitter URL will be ssh://rfay@git-testing.drupal.org:2222/sandbox/rfay/1056659.git.

rfay

Sandboxes can be used for many things, and one of the things they will be used for is for teams collaborating on larger projects, or adding large features to existing modules, etc.

In that situation we have a couple of new complexities:

* We (possibly) have multiple collaborators who can commit.
* If this is a feature of an existing project we will occasionally have to sync it up with that project so we don't have a massive soul-crushing merge when the time comes to do so.

This is one possible workflow for this situation:

1. Create a new sandbox on drupal.org. Mine will be named my_views_feature, and it will be a new feature for the views project. The commmitter URL will be ssh://rfay@git-testing.drupal.org:2222/sandbox/rfay/1056659.git.

rfay

Sandboxes can be used for many things, and one of the things they will be used for is for teams collaborating on larger projects, or adding large features to existing modules, etc.

In that situation we have a couple of new complexities:

* We (possibly) have multiple collaborators who can commit.
* If this is a feature of an existing project we will occasionally have to sync it up with that project so we don't have a massive soul-crushing merge when the time comes to do so.

This is one possible workflow for this situation:

1. Create a new sandbox on drupal.org. Mine will be named my_views_feature, and it will be a new feature for the views project. The commmitter URL will be ssh://rfay@git-testing.drupal.org:2222/sandbox/rfay/1056659.git.

rfay

.DS_Store
._*
*~
*.kpf
*.swp
*.swo

rfay

    // Attempt to determine the Drupal core API version.
    $api = array();
    foreach ($branch->taxonomy as $tid => $term) {
      if (in_array($tid, $api_versions)) {
        $api['version'] = array_shift(explode('.', $term->name, 2));
        $api['tid'] = $term->tid;
        break;
      }
    }

rfay

CentOS release 5.5 (Final)
[rfay@scratchvm tmp]$ git clone git://git.drupal.org/project/examples -b 6.x-1.x
error: unknown switch `b'
usage: git-clone [options] [--] <repo> [<dir>]

    -n, --no-checkout     don't create a checkout
    --bare                create a bare repository
    --naked               create a bare repository
    -l, --local           to clone from a local repository
    --no-hardlinks        don't use local hardlinks, always copy

rfay

  public function apply($patch) {
    return pifr_client_review::exec("patch -p1 -i $patch");
  }

  public function get_changed_files($patch) {
    $contents = file_get_contents($patch);
    // This regex looks through the patch file for lines of the format
    // +++ b/install.php
    // and removes the '+++ b/' from them, returning the filenames that have
    // had content added.