teach appspot.py about git branches

Right now, appspot.py keeps state in a file named .appspot-change,
which is fine when you have a separate svn checkout for each change,
but doesn't work so well if you're putting changes in git topic branches
in a combined git/svn workdir.

This changes appspot.py so that when it notices you're using git,
it stores state in .appspot-change.$GITBRANCH instead.

[ihab.awad, 2009-07-08 05:39:15]

One relatively minor comment below.

However, I'm mainly confused about the use case for this change. Do we ever
check Caja stuff into git? The Caja repo is in SVN and will be for the
foreseeable future....

And why does there have to be a *different* file for when you're using git?
appspot.py does not use SVN or git or any other revision control system; it just
uploads patches.

As I said, I'm confused about the use case. :)

http://codereview.appspot.com/90069/diff/1/2
File tools/appspot.py (right):

http://codereview.appspot.com/90069/diff/1/2#newcode305
Line 305: return path + '.' + re.sub(r'\W', '-', gitbranch)
In other words: If you are using git, the git version overrides? What if you
have both (for some strange reason): why does the git version "win"?

[felix8a, 2009-07-08 11:04:53]

On 2009/07/08 05:39:15, ihab.awad wrote:
> One relatively minor comment below.
> 
> However, I'm mainly confused about the use case for this change. Do we ever
> check Caja stuff into git? The Caja repo is in SVN and will be for the
> foreseeable future....
> 
> And why does there have to be a *different* file for when you're using git?
> appspot.py does not use SVN or git or any other revision control system; it
just
> uploads patches.
> 
> As I said, I'm confused about the use case. :)

I'm using git to manage pending changes and other divergences
from trunk.  It's kind of an experiment.  There are some things I
don't like about it yet, but it's better than what I was doing before.

Your workflow is something like this, right?
For each outstanding issue,
create another workdir that's an svn checkout of trunk,
make changes in that workdir,
post a diff for review,
re-update from trunk,
commit,
discard the workdir.

My workflow is similar, but instead of N svn checkouts,
I have 1 workdir that's a hybrid git repo and svn checkout,
and I put issues on different git branches.

that's why I made this change to appspot.py.  all my
pending changes co-exist in the same directory.
I work on a different pending change with
  $ git co t_pending_foo
which switches my workdir to that branch,
updating only the files that differ.
And eclipse and ant automatically rebuild the minimum.

after a few more iterations, I'll write up what I'm doing
and post it somewhere.  it's a little complicated because
I'm trying to avoid rebase.  it would be simpler if I were
working in private branches, but I'm pushing all of it
to github, mainly for the YUI people.

here's the github repo
  http://github.com/felix9/caja/tree/master

branch 'google_svn' is the pure import of svn trunk.

branch 'google' is 'google_svn' + git-related files,
it's the base for making changes.

branches 't_*' are topic branches, forked off 'google'.

branch 'master' is the integration head,
which merges all the topic branches.

[ihab.awad, 2009-07-08 15:33:33]

Interesting. So -- can you just keep the diffs to appspot.py *itself* local to
your git repo?

In any case, it's important that you make progress conveniently. :) If it would
make your work significantly easier for some reason, then, without further
comments:

LGTM