[plt-dev] Git semi-final repository

Please read this message carefully if you care about historical commit
data and branches.  If you only care about having a new repository and
basic history on it that roughly corresponds to the current trunk,
then you can skip most of it safely.

I've finished converting the repository, and this time I think that I
finally have all the pieces in place -- and it has all the necessary
history (the parts that were required).  It would be a good idea to
check it anyway -- especially around the neighborhood of non-standard
branches that were copied from some subdirectory.  (I pretty much did
these things by manually analyzing what went on and replaying commits
into the right places.)  (Sam: these are mostly yours.)  On the plus
side, I can now easily pull new revisions from svn, which means that
I'll keep it updated and if everything is fine then this will be the
new repository.

The reason that I need testing soon is that fixing commit ancestry
issues involves those "grafts" that I mentioned earlier -- this is an
external file that specifies explicit commit parent-child relations
overriding what's actually stored in the repo.  This data is volatile
since it's not an official part of it (for example, you won't get it
when you clone it).  Once that's done, I'm running a process that will
replay the full repository, which turns thee grafts to be part of the
commit information (they're part of the sha1 checksum, which is why
this is needed) -- but that means that older copies of the repo will
not work right.  Therefore, if there are any mistakes, I need to know
about them before the switch, so I can rebuild the repo again.

A note about branches: there are two kinds of branches -- live ones
and dead ones.  Dead ones are those that were merged to the trunk
(which from now on is known as "master") so there is no use for them,
and ones that were not merged to the master.
* The dead ones are not necessary: removing them leads to no loss of
  any data, and I will do that if everything looks good -- but for now
  I kept them for the value of being reference points so you can check
  that they look fine.
* The live ones are needed, of course -- they're leaves in the commit
  tree and if they're removed then the commits they point at (and no
  other commit points at) will eventually be garbage-collected away.
  So for these, I will wait for a while (*after* we've converted to
  git) for their owners to get them, and then I will remove them from
  the central repository.  This is because they're all individual-use
  branches -- it's questionable whether we'll need any branches
  maintained on the server, but at least in the early stages I want to
  avoid that until things are more clear.  (Ryan: this includes your
  live branch, which I also reconstructed.)

I've made the result into the "play" repository that is setup in the
same way that the plt repository will be set up -- all except for a
few final touches on the notification emails, which I'll catch up with
shortly.  Specifically, you can try to clone it, inspect what you get,
commit, and push back in -- except for these notification messages,
everything should work as with the real tree.  A few notes about these
games:
* There is no problems with any damage and random junk on this
  repository, since it's a copy of what I converted and will
  eventually use.  However, try not to damage branch data (that is,
  avoid trying to delete converted branches) because I need the above
  feedback.
* I might reset it from time to time (that is, remake stuff in a way
  that will confuse clients -- things that would not happen in normal
  operation) as needed, but I'll say something when it happens.  The
  bottom line is that you should be ready to just remove your copy at
  any time: so don't do any real work with it.
* The setup includes a github mirror, which is getting updated on
  every push to it.  So modulo a few seconds delay, the github copy
  should be as good as the copy on the server.
* With github there is a package of stuff that we get --
  - some general niceties (nice interface etc),
  - some social value (anyone can clone it from there),
  - some nice technical features (eg, an svn interface for the repo
    (read-only, and works only with the master branch, IIUC)),
  - some features that will not be used at least for now (issue
    tracker, wiki, fork queue),
  - and a bunch of hooks that github knows how to speak (like sending
    tweets on pushes, sending an email (which might be better than the
    code I wrote for this), IRC, Jabber, and just for Jon: CIA).  It
    also has a generic hook for a URL that it will send a POST request
    to, as a generic hook for further extensions.  I do have tweeter
    notifications (the login is "racketlang"), and emails (which go
    only to me, for now).

You can access the repository in these places:
* Public read-only access:
  - gitweb interface:    http://git.racket-lang.org/play/
  - github mirror:       http://github.com/plt/play/
  - http access:         git clone http://git.racket-lang.org/play.git
  - git protocol access: git clone git://git.racket-lang.org/play
* RW access for developers:
  - ssh:                 git clone git at git.racket-lang.org:play
  - ssh with config:     git clone git:play
    (This can be done with a "git" entry in your ssh config file;
    later on I will provide instructions on how to set it up.)

BTW, I used racket-lang.org for emails.  One side effect is that if
you've put an image on gravatar, then you'll need to do it again for
this domain.  (Reminder: I think that it's a good idea to do this:
it's used by github as well as the gitweb interface, and it's a nice
way to get more information at a quick glance.  So please do it if you
didn't -- feel free to ask me to do it for you.)

The plan for the migration is:
* The next big thing that I need to do is write detailed instructions
  for using git.  I hope to cover most of the basic use cases which
  should be sufficient to switch.
* In the meanwhile, I'll continue to mirror svn commits to keep the
  git clone in good shape.
* When the above is done, and things look good enough (probably a few
  short days), I'll announce a time when I'll shut off write access to
  the svn repository and turn it on for the git one.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!