(Work in progress, comments are welcome)
The aim of this patch is to implement a function that builds a
zip archive from the pristine tree of a repository.
This would enable darcsden to have a "Download ZIP" button, like Github
currently has (see for instance <https://github.com/jgm/zip-archive>).
The idea is to help people who do not have darcs installed to
easily retrieve the last version of any repository hosted on darcsden,
thus reducing lock-in and frustration.
We already have a `darcs dist` command that generates a tar.gz
archive from a repository. It accepts matchers (--tag for instance)
and the --set-scripts-executable flag.
However in the case of "Download ZIP", reusing the code of darcs dist
to generate a zip file did not seem good to me because:
* `darcs dist` creates a temporary working copy and then
compresses it, this is quite inefficient (for a website that
may host many and big repoitories)
* a "download zip" button would only care about the last version
* zip files do not store executable flags anyway
So I implemented two functions: Darcs.Repository.HashedIO.pathsAndContents
that returns a list of pairs (FilePath,B.ByteString) of the whole
pristine tree (with paths rooted at a path given as argument),
and Darcs.UI.Commands.Dist.doFastZip that generates the zip file
from a repository.
The patch introduces a dependency on zip-archive, which seems to
be the best haskell module to create zip files. It is written by
John MacFarlane who uses it for its program Pandoc. The new dependency
on time is needed to get the current time when creating zip file.
I introduced it after looking at pandoc's code.
Things are not perfect, here are some issues:
* Can we get rid of the new time dependency?
* I just opened <https://github.com/jgm/zip-archive/issues/19>
since zip-archive seems to generate incorrect zip files.
This is not our bug but it would be nice to see if it gets fixed.
* The new pathsAndContents function of HashedIO is quite ad-hoc.
* pathAndContents returns strict bytestrings, is that a problem?
* do we really want doFastZip inside of darcs, or in darcsden?
I'd rather have it inside of darcs (for responsibility and
maintainability sake). Then a --zip flag for `darcs dist` would
make sense.
To try the patch, apply it, replace `commandCommand = distCmd`
by `commandCommand = doFastZip`, compile and run `darcs dist` in
some repository.
1 patch for repository http://darcs.net:
Thu May 15 16:35:14 ART 2014 Guillaume Hoffmann <guillaumh@gmail.com>
* implement doFastZip to create zip archive from pristine tree
Attachments
|