[bug#71371] [PATCH v2] gnu: svn-fetch: Allow specifying revisions as strings.

[Nicolas Goaziou via Guix-patches via <guix-patches@gnu.org>]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> * guix/svn-download.scm (<svn-reference>):
>> (svn-fetch):
>> (svn-multi-fetch):
>> * guix/build/svn.scm (svn-fetch): Revision can also be a string, not only
>> a number.
>> * doc/guix.texi (origin Reference): Document changes about REVISION field.
>>
>> Change-Id: Ibb17b539575fdf3daf895bd1ce39a40dd9b495cb
>> ---
>> v2: No longer ignore "-r" argument. Instead, allow strings, such as "HEAD". Yes, in practice, it means this relies on the tag being stable, which is the same assumption as for, e.g., tarballs. WDYT?
>
> While it may be useful to point to volatile references such as HEAD for
> internal projects (like I believe is also possible for our git fetcher)
> or the likes (with a hash of #f for example), I wouldn't like to see
> this used in the Guix tree (I'd consider it a bad practice).  I'm not
> against merging this, but I think we should add a 'guix lint' rule
> that'd warn that some SVN reference should be specified if it wasn't.
>
> Does that sound reasonable?

To be clear, I intend to use it in Guix tree, _in conjunction with
a tag_. The purpose of this patch is to put the reference on the
human-readable repository tag, not on the revision number.

Sure, as already pointed out, some evil repository could modify contents
associated to a tag because Subversion allows it. But that would defeat
the whole purpose of tags, so I don't think that's common at all. Tags
are not meant to be volatile.

Again, as also pointed out, we trust tarballs, but the situation is
exactly the same for them: one evil project could modify the contents of
the tarball without changing its name. The consequence would then be the
same: a hash mismatch.

Anyway, this patch is there to make my life less miserable while writing
a TeX Live updater. It is of no use (to me) if it is restricted to
internal projects. I'm not putting pressure on anyone though, if it
isn't accepted, I'll find other, probably more tedious, ways to complete
the updater.

Regards,
-- 
Nicolas Goaziou