Support for downloading tarballs from the repository

[cathelijne@…]

It would be cool to be able to browse the repository and download a tarball of a branch or tag.

[daniel]

While presumable a cool feature, it'll possibly take up a lot of resources and bandwidth.

If done though, adding a "download directory as tar/zip-ball" feature to the Browser would suffice.

[Christopher Lenz]

#814 marked as duplicate of this ticket.

[Christopher Lenz]

This shouldn't be so hard… have a look at the zip file support in Changeset.py for an example of how to package up files in a ZIP file.

[Christopher Lenz]

#1504 has been marked as duplicate of this ticket (although it limits the request to files as opposed to whole directories). It also contains a patch for enabling this.

[Christian Boos]

Note that this feature would also solve #763.

[Christian Boos]

This is implemented in the TracDiff branch.

[Christian Boos]

This will be post-poned to 1.0, as this is part of the TracDiff branch.

[Christian Boos]

This ticket depends on #2028. Go there for the patches against 0.9.x.

[Christian Boos]

mgood suggested that this feature could put some load on the server. While that's certainly not an issue with small repositories, that can be a problem for big repositories, so it should be possible to disable this feature:

[browser]
download_archive = false

However, a better solution might be to allow the download of some selected paths and cache the corresponding .zip files:

[browser]
restrict_download = tags/trac-0.8.1, tags/trac-0.8.4, tags/trac-0.9b1

Of course, the revision should be taken into account, which may complicate matters (e.g. cache a maximum of 5 different revisions for each specified path).

[ttest]

I don't know if it would be a good idea to restrict the downloadable directories in the configuration file, since than you would have information in there about the structure of your repository. IMHO it would be better to put the information which directories are downloadable/not downloadable in the repo. itself. Properties would be perfect for this.

[Christian Boos]

answering ttest: not every VersioningSystemBackend has support for properties (e.g. Mercurial doesn't)

[Christian Boos]

Note that the feature is now available in trunk. I leave this open until there's some consensus about the form that should take the "control" of this feature. What we have so far:

• usage of properties is ruled out because that would be specific to TracSubversion
• some possible TracIni settingss:
  • enable_download for enabling or not that feature
  • restrict_download using a glob pattern to define the paths where a download is possible. e.g.
    • "*":: everywhere
    • "tags/*":: only below the tags folder
    • "":: nowhere

[Christian Boos]

Implementation of the previous idea (list of glob patterns)

Index: trac/versioncontrol/web_ui/browser.py
===================================================================
--- trac/versioncontrol/web_ui/browser.py	(revision 3006)
+++ trac/versioncontrol/web_ui/browser.py	(working copy)
@@ -17,6 +17,8 @@
 
 import re
 import urllib
+import os.path
+from fnmatch import fnmatchcase
 
 from trac import util
 from trac.util import sorted
@@ -154,7 +156,10 @@
 
         req.hdf['browser.items'] = info
         req.hdf['browser.changes'] = changes
-        if node.path != '':
+        patterns = self.config.get('browser', 'downloadable_paths')
+        if node.path and patterns and \
+               filter(None, [fnmatchcase(node.path, p) for p in
+                             patterns.split(os.path.pathsep)]):
             zip_href = self.env.href.changeset(rev, node.path, old=rev,
                                                old_path='/', # special case #238
                                                format='zip')

Of course, the most difficult here is to find a sensible configuration setting name and a sensible default:

• "*": all folders are downloadable
• "": none are downloadable

[Alec Thomas]

This would be incredibly useful for TracHacks!

[sid]

This feature will probably be used most in root level directories (trunk, branches/0.x-stable, tags/…), not all over the place. In the case where it might be used in a broader fashion (e.g. TrackHacks), it means there are probably a lot of smaller projects and less overhead to create new archives as needed.

I think the globbing is overkill.

How about:

[browser]
enable_archive_download = true

[Christian Boos]

The problem is that there are no fixed rules for identifying what is a root level directory…

E.g. you would like to make each release (/tags/release-x.y.z) downloadable, but certainly not the whole /tags folder, which might contain dozens of releases…

Other example, in Trac hacks, the glob pattern would be /*/*, i.e. anything at the second level, like /authformplugin/0.9 but not /authformplugin itself.

IMHO, a global yes/no flag is useless… Sure you may want to disable the feature completely, but when you want to have it, you want to have some reasonable control over it, as examplified above.

With the glob patterns, complete disabling is very easy, simply leave the option empty, and if control is needed, I can't think of a better compromise between simplicity and flexibility than a list of glob patterns…

[Alec Thomas]

I agree, globs seem like an excellent choice. I certainly wouldn't want people downloading the entire TracHacks repository.

[Christian Boos]

Implemented in r3117.

[Christian Boos]

Note that in the future, it might be worth to use a cache for the zip files, as they can be costly to create.

[Alec Thomas]

I've updated to trunk on TracHacks and this is working beautifully, thanks Christian :)

A cache would also be quite useful.

[stepan@…]

Is it possible in a similar way to create "real" tar balls (not .zip files) instead?