Issue #6007 open

Download filenames should include the branch or tag downloaded, not the hash (BB-7263)

ralesk
created an issue

I couldn't find an issue about this, so here goes, my first try at reporting anything :)

How it works currently

The folder name in a tag/branch tarball is $user-$repo-$node, for example.

I understand that the node ID is unique and specifies very well what the tarball contains, but as SHA hashes are by definition unpredictable, it's impossible to automate with them. For example, in the distro I use and package for, there's a simple script that fetches the source, and of course it's a lot easier to specify a version string than something random. Even other than automation, you extract something and get eg. xi-pyyaml-607628291e74/, how do you know later on, which of your xi-pyyaml-* directories is the one you want?

What would be nicer

To solve this, I guess it would be better if tag downloads would contain instead the tag name (eg. xi-pyyaml-3.10), and it might also be useful if the branch downloads contained the branch name somehow too, though I'm not exactly sure about its usefulness.

Maybe for Hg repos where the local revision ID is defined (I know Git can't do this), if you approach the download from the revid, get a revid into the download's folder instead of the node. Yes, it's not unique and precise, but public repos shouldn't be history edited anyway. Still much more human-friendly than the random hash.

Comments (7)

  1. Jon Mooring staff
    • changed status to open

    Hello,

    Thank you for taking the time to submit this suggestion. I agree that the naming conventions for downloaded files could be better. I've created a ticket in our internal tracker and will update this issue if and when we decide to make these changes. I'll also be leaving this issue open for additional feedback from the community.

    Thanks,
    Jon

  2. raymonad

    I did find a previous issue for this: #3486. Not reverting an inadvertently introduced change seems a bit strange, though, especially since the change in behavior is also strange. I mean, tags are used to refer to a specific commit by some meaningful and easy to remember name instead of the hash, but the current naming scheme means that you still need to know the hash to get to the file after downloading.

    If you decide to fix this (and I hope you do), perhaps you can use new URLs for downloads with improved names, but still accept the old URLs for scripts relying on the old naming convention.

  3. Guido Draheim

    +1 for fixing this issue.

    There seems to be a download URL like $(repo)/get/$(tag).tar.gz that one could use to automate the download process. The real big issue is that the node name is also encoded into the tarball where the initial subdirectory does not use the tag name.

    This breaks rpm spec scripts relying on %name %version for the %setup macro

    AFAIR it had been different at bitbucket? Actually I did not like the hashtag-encoding feature of github being another motivation to evade that other site.

  4. Matthew Moses

    Implementing this fix would really help me out too. I'm currently cloning the repos I need, manually creating the archive, then uploading the archive to an appropriate storage service (usually the "Downloads" area for the repo). This gets cumbersome, especially if I need to do it for someone else's repository.

    I can see some utility in the current scheme, but I think the proposed change has even more utility, especially if you're writing scripts to automate some process.

  5. Log in to comment