[racket-dev] proposal for moving to packages: repository

We already have a system for constructing a script that can move files
around and adjust content as needed: git.

As long as some of us are trying to write that script while others are
changing the existing directories and files, there will be collisions.
We won't come up with a scripting system that handles those collisions
better than git.

I want to minimize conflicts and maximize the number of people who can
help refine the package structure. We all know how to use git to script
changes to the repo, and we know how to work with a shared repo to make
conflicts manageable. That's why I'm asking that we all change together
to a new repo structure.

I think a lot of people on this list are eager to contribute to the
shift into packages. As someone close to the new structure, I'm telling
you my best guess at how you can help and in be in a position to help
more: let us switch the repo sooner rather of later. Then, everyone
will be in a good position to "script" progress in various ways.


At Tue, 21 May 2013 14:20:33 -0400, Eli Barzilay wrote:
> Yesterday, Matthew Flatt wrote:
> > 
> > Concretely, new repositories that are just a subset of the current
> > repo would be off-by-one in directory structure compared to a normal
> > package. Each package should correspond to a subtree starting from
> > the "collects" level, not the parent of "collects". We could massage
> > the two views into one, but I'd rather not.
> 
> That's really easy to deal with, and doesn't contradict what I
> suggested, *but* given:
> 
> > To put it another way and overstate a little: I'm trying to get buy-in
> > from dev to make the switch to packages wholesale. [...]
> 
> And even more, given:
> 
> 5 hours ago, Matthew Flatt wrote:
> > I think we won't get an ideal package split on the first N tries,
> > and it will be easier to move files and directories around in one
> > repository (using `git mv') instead of among multiple repositories.
> > When we finally have mostly the right split, then we can use `git
> > filter-branch'.
> 
> I think that there's a much easier and more elegant way to do this,
> which is even easier for all developers.  Roughly speaking, it's
> flipping what I suggested yesterday and doing it the other way:
> 
>   * Keep the repository as-is, no structural changes at all.
> 
>   * Keep working on things as usual, including work on the package
>     system and everything that is related.
> 
>   * As it gets to a workable state, keep a script that will *split*
>     the monolithic repo into separate packages.  This script can start
>     very simple, for example, a naive thing would be:
> 
>       cd $MAINTREE
>       mkdir $PACKAGES/drracket
>       mv collects/drracket collects/drscheme $PACKAGES/drracket
> 
>     Everything that deals with packages would start from a fresh main
>     repo and and empty package directory, and will construct the
>     packages from it.  So, for example, the build will still make each
>     package independently, and distribution is still done by
>     assembling packages.
> 
>   * The main point is related to what you said above: the package
>     splittage is determined by the script, so if you find out that
>     some file belongs in a different package, or that packages need to
>     be combined, or split differently, or whatever -- this is all done
>     by just changing the script.
> 
>     So you get two birds with a single stone: it's easy to experiment
>     freely in the early stages, and it's easy to adjust things when
>     the split converges to something that works fine.
> 
>   * When everything is working smoothly -- with the main effect being
>     a resolution of dependencies, both of existing code and in terms
>     of people being aware of them -- at this point it will be a good
>     time to switch to separate repos, and since all developers have
>     already gotten used to the package, there is now just the repo
>     change, and nothing else -- so it becomes a technical point like
>     switching from svn to git, not piled up on the more substantial
>     change.
> 
>     As a side-effect, the final directory-splitting script can be used
>     with git's filter-branch to create the new repos.
> 
> I think that this offers the best in terms of being flexible as needed
> while work is in progress, and separating the changes that people need
> to adjust too which should make the whole process more comfortable.
> 
> -- 
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!