Repository Reorganization Question

[Simon Marlow]

Trac tickets with links to commits are the important case.  If the 
commit IDs change, someone will have to run a script over the Trac 
database and rewrite all those links to testsuite commits to the new 
ones.  Sounds possible, but it'll be at least a few hours work I'd guess.

I'm in favour of removing the unnecessary binary blobs from the history 
so long as we can do it without any serious disruption.

Cheers,
Simon

On 06/12/2013 12:50, Johan Tibell wrote:
> Whichever way to go, we should write down the options and consequences
> and communicating them widely enough so no core devs get surprised.
>
> Commit IDs for the test suite are referenced in e.g. various Trac
> issues, on mailing lists (although rarely), and perhaps even in code.
>
>
> On Fri, Dec 6, 2013 at 1:15 PM, Herbert Valerio Riedel <hvr at gnu.org
> <mailto:hvr at gnu.org>> wrote:
>
>     On 2013-12-06 at 13:01:41 +0100, Johan Tibell wrote:
>      > When we merge in the testsuite repo, can we still keep the old
>     commit IDs?
>      > They're referenced from all over the place.
>
>     ...if we want to preserve the old testsuite's commit-ids, then we'll
>     have to live with carrying around those superflous large blobs in
>     testsuite's history nobody really needs, as afaik[1] we can't remove the
>     blobs w/o causing the commit-ids to change.
>
>     I'm not so much concerned about disk-space, but rather the wasted
>     network bandwidth involved (and yes, we're already suffering from that
>     now with the current testsuite.git). But I don't feel very strongly on
>     this one, if there's agreement that we want to keep around those dead
>     weights in the Git history in order to retain testsuite.git's original
>     commit ids *inside* ghc.git (nb: the old testsuite.git repo won't be
>     deleted and thus remain available, it just won't be pushed into
>     anymore).
>
>     Otoh, which use-cases exactly do you have in mind wrt the testsuite.git
>     commit-ids?
>
>
>       [1]: maybe someone with more Git-foo knows a trick here?
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>