[plt-dev] Git semi-final repository

All of this sounds like a serious step backward for /usr/ directories  
and I seriously question the move to git now.



On Apr 15, 2010, at 10:32 AM, Eli Barzilay wrote:

> 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!
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev