[plt-dev] Git semi-final repository

I have used svn a lot to collaborate with groups of people and Eli's telling me to send patches through email instead. I might as well use floppies again. 




On Apr 15, 2010, at 2:49 PM, Robby Findler wrote:

> Why do you draw that inference?
> 
> Robby
> 
> On Thu, Apr 15, 2010 at 12:36 PM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>> 
>> 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
>> 
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>>