Update gyp DEPS

Update gyp DEPS

R=djsollen@google.com

Committed: https://code.google.com/p/skia/source/detail?r=10266

[borenet, 2013-07-22 20:38:28]

This includes my gyp change to allow generating projects on a different drive in
Windows (https://codereview.chromium.org/18991011/).

[djsollen, 2013-07-22 20:49:48]

does the gyp team have branches or tags you can follow? My guess is probably
not, but if they do they are easier to read in the DEPS files. :)

[borenet, 2013-07-22 20:51:39]

On 2013/07/22 20:49:48, djsollen wrote:
> does the gyp team have branches or tags you can follow? My guess is probably
> not, but if they do they are easier to read in the DEPS files. :)

No idea.

[djsollen, 2013-07-23 14:44:22]

lgtm

[borenet, 2013-07-23 14:47:00]

Committed patchset #1 manually as r10266 (presubmit successful).

[epoger, 2013-07-23 15:05:34]

On 2013/07/22 20:49:48, djsollen wrote:
> does the gyp team have branches or tags you can follow? My guess is probably
> not, but if they do they are easier to read in the DEPS files. :)

You've piqued my curiosity, Derek, as I try to wrap my head around git.  Do you
mean a git commit identifier that's more meaningful than
"e5179456241c17cb6cdd106e4744882d32081df5" but points at the same version of the
gyp code?

I would think that we would want our code to depend on specific, absolutely
known versions of other code, rather than "latest commit on branch XXX".  After
all, we could just depend on "latest commit on the trunk" but we don't do that,
because who knows what changes might get introduced…  so, by that logic, we
wouldn't want to depend on a "branch", right?

So, I guess the other possibility is a human-readable tag that refers to not
only a branch but the particular revision on that branch.  In other words, an
alias for commit ID e5179456241c17cb6cdd106e4744882d32081df5 .  Right?

[djsollen, 2013-07-23 15:14:27]

Yes, there is the possiblity that they could change what the tag alaiases to
from under you, but there are some branches/tags that can be assumed to be
fixed.  For example the AOSP (android open-source) has tags for major releases
(e.g. 4.2.2) which is expected not to change.

[epoger, 2013-07-23 15:28:51]

On 2013/07/23 15:14:27, djsollen wrote:
> Yes, there is the possiblity that they could change what the tag alaiases to
> from under you, but there are some branches/tags that can be assumed to be
> fixed.  For example the AOSP (android open-source) has tags for major releases
> (e.g. 4.2.2) which is expected not to change.

Aha, as documented at
http://source.android.com/source/build-numbers.html#source-code-tags-and-builds
, an example tag on that tree is "android-4.2.2_r1".  Nice that they maintain
those.