[plt-dev] Git semi-final repository

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
>