[plt-dev] `usr' repository and git

[Dave clarified that his question was re the usr repositories, so I
might as well talk about that.]

What I plan to do with the usr repositories is "not much":

1. You will have a way to create new repositories on the plt server,
   in your own directory.  (For example, I'll be able to create a
   repository at a directory like usr/eli/foo.git or just eli/foo.git
   or something like that.)

2. These repositories are completely under your control, which means
   that you do whatever you want with them.  I can provide some
   guiding points on how to port your stuff, but what you actually do
   there is completely up to you -- including porting your svn
   repository.  (Specifically, you can run git-svn to clone from your
   svn.plt-scheme.org/usr/<user>/some/path, then push the resulting
   repository to the plt server into your path.)

Additional related notes:

* The svn repository will be up for a good while.  (Depends on how
  easy it is to keep it up, and if that's going to just keep working,
  then most likely for at least a year.)  In any case, the *data*
  itself will always be there, even if a server isn't working.  (For
  example, we still have the cvs server working...)

* The reason for doing this is only for specific cases:

  - If you don't need to share your work with anyone, you can just as
    well keep your repository on your own home directory.  The only
    benefit you'd get from a plt repository is an additional backup,
    but most cs depts should give you a backup that is just as
    effective.  (And if you're at NEU, then it's the same place that
    it's backed up at...)

  - If you want to share your work with *everyone*, you can just as
    well create a public repository on github or a similar place.
    That is certainly going to be easier for you to setup (and with a
    fancier interface) than what we'll offer...  (Specifically, I am
    very unlikely to setup the web interface for the user
    repositories.)

  - If you want a repository that is shared with a few known people,
    then there are several options here:
    - Use a shared directory on a machine that you and your
      collaborators can access and read/write to.  Or set up an
      account for you and the others, or something like that.
    - Set up a private repository and communicate patches via email,
      git intentionally makes doing so easy.
    - Get a private repository on github or other places.  (To give
      you an idea of what you can get: github gives you 5 repositories
      for $7/month, beanstalkapp.com gives you 1 repository for free,
      projectlocker.com gives you 500mb space for free but the web
      interface has ads, indefero.net gives you 50 private
      repositories and unlimited users for free but 10mb space,
      unfuddle.com gives you 1 free repository; see more at
      https://git.wiki.kernel.org/index.php/GitHosting.)
    - Keep in mind that if you're using this to share work on
      something temporary like a paper, you can remove the repository
      at the end of your work, since your clone contains the complete
      history.

* If none of the above fits your needs, then you might find a plt
  repository useful after all...  If you don't have push access to the
  main server (ie, if you don't have write permissions to the plt tree
  on svn), then you'll need to send me a public key to use.  Also, if
  you need to collaborate with others and you want to do so through
  our server, then I'll need a key for the other people too.  (But in
  general, getting random people in and out has made things more
  difficult to manage so I hope to avoid much of that overhead.)

* Finally, note that one nice property of svn is that you're mostly
  independent of where the root of the repository is.  In other words,
  every subtree of a subversion repository can itself be viewed as a
  repository -- for example, you can pretend that /usr/foo/blah is a
  different repository from /usr/foo/bleh.  When you migrate to git,
  you will need to find some natural separation of your stuff to
  separate project, and use that to migrate.  Note that a paper should
  in almost all cases be a project -- for example, consider the fact
  that the complete history is contained in a repository, so if you
  work with Foo on a paper using a repository that you used for work
  with Bar, then Foo will see the history of that work too.

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