[plt-dev] Git semi-final repository

It's about the commandline, it's about the /usr/ sub-trees. 
We have a bunch of stuff in /usr/ trees that we share with 
the subset of people that matters (papers, books, private 
programs, web trees, etc). With svn, you just set up authorization
and it all works. With git, it's too complicated so everyone 
sees everything or something like that. 



On Apr 15, 2010, at 3:24 PM, Robby Findler wrote:

> The options we had with SVN are still open, IIUC. Indeed, I only know
> a little of git, but I believe there is a usage pattern that does not
> take advantage of fancier gitness that even works exactly like how svn
> works now (altho the messages that you get in reply are a bit
> different), namely that you always "push" after each "commit" (ie,
> git's "commit" followed by git's "push" is almost exactly the same as
> svn's "commit").
> 
> I think we should stick with git.
> 
> Robby
> 
> On Thu, Apr 15, 2010 at 2:21 PM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>> 
>> I do have some old punchcards somewhere. Everything I hear is "this won't work on git" and "that's too complicated with git" and you have to create an account for your friends on your personal computer to share work and then pay some random guy $7.13 too. This is all stupid.
>> 
>> 
>> 
>> On Apr 15, 2010, at 3:16 PM, Robby Findler wrote:
>> 
>>> I think that Eli's telling you that you can collaborate with such
>>> people without them having to have accounts that hang around on the
>>> main plt servers. You can collaborate with them without email if you
>>> share some filesystem somewhere with them, or if they have a github
>>> account or .... probably there are other things before you have to
>>> pull out the beta tape player.
>>> 
>>> Robby
>>> 
>>> On Thu, Apr 15, 2010 at 2:13 PM, Matthias Felleisen
>>> <matthias at ccs.neu.edu> wrote:
>>>> 
>>>> 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
>>>>>> 
>>>> 
>>>> 
>> 
>>