On Tue, 08 Oct 2013 14:50:24 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
On Tue, Oct 8, 2013 at 2:31 PM, j. van den hoff
<veedeeh...@googlemail.com>wrote:
coming back to this problem of "problematic" character such as `/'
causing
tar/zip download to fail since the
URL generated by fossil is invalid: would it not be sensible to simply
use
as name the sha1 hash itself plus the suitable extension,
e.g something like
ae9ca63258d41bda7b7ca968b65dde**caef1a742b.zip (or, preferably,
abbreviated to 10 chars of the hash as in the timeline)?
That does indeed sound like the most bullet-proof mechanism, though
perhaps
not the most user-friendly. Once downloaded, the user is going to
practically be forced to rename it.
I would say: as he is currently, too, in general. I suspect for most users
it will seem natural to choose a descriptive free text project name and
then the zipfile name ends up as something like (this is a real world
example...):
sd+--+a+drop-in+replacement+for+`cd'-ae9ca63258d41bda.zip
which is not especially inviting to keep this as the final name of the
unpacked archive dir...
this seems to have 3 advantages:
1) no interference anymore with user's choice of project name and valid
file name on all platforms
2) file name still sufficiently "unique" to avoid accidental names
clashes
on the local disk
3) it should be the path of least resistance regarding fixing it in the
source code
Agreed on all 3 points, but it sure would be ugly. :/
see above: I don't think it is _that_ beautiful right now. ;-)
renaming of the unpacked archive directory to something more
recognizable
(if so desired) might be left as an exercise to the user I'd say ...
The vast majority of project names unpack just fine currently. This
I don't have any statistics for that (but it might be true). nevertheless
it is _very_ easy to stumble over this right now and it seems fossil would
benefit from fixing this issue.
and also see my example above: that one does unpack just fine but I'm not
happy with that name either and sure would change it soon.
proposal (while arguably better at a technical level) increases the
amount
of work for everyone who _doesn't_ use special characters in their
project
names. That's my biggest (possibly only) argument against it. It also
might
complicate scripting because one now no longer has some common string to
use as a wildcard basis (except for *.zip/*.tar, which may be too generic
for some scripting purposes).
not sure whether that is a widespread demand (handle multiple downloaded
zipfiles via scripting). but if it is, one could prepend some fixed
string, e.g. use a name like
fossil-ae9ca63258d41bda.zip
that should at least handle all within-project activities related to
handling multiple zip files from the same timeline.
what do others think in this regards?
i'd like to see this combined with David G.'s hash-to-name idea, so that
the Zip files get named like ORANGE BATTERY HORSE ;).
well ...
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
