[Haskell-cafe] fptools in darcs now available

[John Goerzen]

On Thu, Apr 28, 2005 at 03:08:14PM +0100, Simon Marlow wrote:
> On 28 April 2005 14:26, John Goerzen wrote:
> There's already an old version of darcs installed (0.9.18), and darcs
> repos in /home/darcs.  Cabal is kept there, for example.  We need to
> upgrade that version of darcs, I presume - can you point me at an
> appropriate RPM?

There are some links at
http://www.darcs.net/DarcsWiki/CategoryBinaries#head-c117ab04e58976d0ca75e5b2e2a2207e221df78e

I don't know what distro cvs.haskell.org is running, but one of those
should work.

> > 3. Rename the smaller project's files as appropriate
> > 
> > 4. Checkpoint here
> 
> Won't that leave a lot of useless history in each individual project?
> When I do 'darcs get' locally to check out a few sub-repositories, won't
> I get N copies of all the old history?

Yes, but they'll all be hardlinked together, so no matter how many
copies you get, the old history is only stored on disk once.

If you do this locally on cvs.haskell.org, you may not even wind up
consuming any extra disk space.

Also, if you don't really care about the history prior to the Big Split,
then it's almost a non-issue.  Checkpoint after the Big Split, and
just do a get --partial.  As time goes by, that older history will
probably tend to be less and less important.

I bet some darcs hacker could come up with a script that would even let
us remove the patches from a descended repo that don't apply anymore.

I know it's not ideal, but trying to manually convert each part of the
CVS repo, one at a time, is far, far less ideal.  Not something I care
to attempt, anyway :-)

The other thing is that having a big repo in darcs may turn out to be
not as bad as we all thought at first.  The only really annoying thing
there is how long it takes to do an initial darcs get (~5 min for me if
I use --partial).  Other than that, darcs performs quite nicely.

It may be useful to explore the plusses and minuses of splitting it up.
In my mind:

Benefits to a split design:

 * More fine-grained control over commit access on the server to each
   part

 * More fine-grained control over where patches are sent for review

 * Faster get and checkpoint operations

 * Makes sense if most people mostly work on one particular subsection of
   fptools only

Benefits to a unified design:

 * Less administrative work

 * Permits easier gatewaying with CVS

 * Permit changesets that cross project boundaries (there are a
   surprising number of these)

 * Easier to keep projects in sync with each other

 * Easier to just "darcs get", hack, then "darcs send" for people to
   contribute (no need to worry about config scripts or checking out
   the appropriate repo for a subproject)

 * Make sense if people mostly work on fptools as a whole 

> BTW, one thing I've always wanted is a hyperlink in the commit mail that
> takes me straight to the patch.

Nice idea.  Or we could even attach the patch; one could then save and
"darcs apply" it locally.

-- John