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

On Friday, Matthew Flatt wrote:
> At Fri, 24 May 2013 12:44:35 -0400, Eli Barzilay wrote:
> > > > * The script should also take care to deal with files that got
> > > >   removed in the past.
> > > 
> > > Ditto.
> > 
> > I don't believe that it's *not* doing this, so I did the
> > double-check in the form of a test.
> 
> You're right --- I misunderstood your example.

(BTW, in case it wasn't obvious -- that was a typo, since the script
is not doing it...)


> Still, I'm happy enough with the result in your example. The
> conversion does preserve `git log --follow' results for the files
> that survive, which was my intended spec. And maybe it's better to
> explain my interest as `git blame', since my main interest in the
> history of a file is often how/why a particular bit of code ended up
> as it is.

Ah, yes -- in that case, I think that it's doing that (= maintaining
the blame information) fine, but there are still things that you'll
want to keep.  (At least for some value of "you"...)

(I'll get back to this later, since it's the main content.)


> >   * filter-branch one time using your script to reorganize the files
> >     according to packages
> >   * use filter-branch with a subdirectory filter 5 times to create
> >     each repository
> >   Total runtime: about 21 hours
> > 
> > This latter use would end up with the final tree being exactly the
> > same (since you're talking about doing the reorganization within
> > git), but the history would be different since it's as if the
> > files were there the whole time.
> 
> I don't see how that works. Since my script leaves each file in its
> original location for old commits, I expect a subdirectory
> `filter-branch' to still drop history for the old locations. In any
> case, I'm happy to sort out that detail later.

Ah yes, keeping the files in-place instead of shuffling them around is
definitely much better.  And yes, it means that it *will* take that
large chunk of time for each extracted repository, but I think that
it's definitely worth the effort.  (Once there is a good way to do the
whole trimming thing, I can easily script that onto a bunch of lab
machines to do it all in parallel.)


> If we agree that `git mv' before splitting is practical, though,
> that's all I need for now.

Yes -- with all of the above, and with the additional improvements
that I'll suggest below.  Actually, I'll just send that in a new email
since it's long enough.


> From my perspective, the important thing is to have the ability to
> just edit and move files around to sort out packages, instead of
> having the indirection of a script that edits and moves files
> around.

OK -- but I still think that it's worth it to save a second major
change for people, and given that you've started with a suggestion for
package splitting, maybe just go on with revising that for a short
time and then just do the splitting without an intermediate period?
For people who want to keep dealing with the whole "tree", the layout
is going to be the same so there won't be much difference anyway, and
people who want to deal with just their corner will get more time to
adjust and enjoy the benefits of dealing with just their corner
quicker.

BTW, it will potentially lead to more problems where my change to my
own repo goes fine and I don't know that it got broke because of a
change elsewhere since I didn't keep the other files in git form --
but this makes me think that the next release might be prone to such
issues, so it's better to start earlier with the segregation rather
than doing it later.  (But OTOH, the builds and drdr will keep a high
level of problem prevnetion, I hope.)

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