[bug#71371] [PATCH] gnu: svn-fetch: Make revision field optional.

[Nicolas Goaziou]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> skribis:
>
>> -@item @code{revision}
>> -This string denotes revision to fetch specified as a number.
>> +@item @code{revision} (default: @code{#f})
>> +This field denotes the revision to fetch, as a number.  It can also be
>> +set to @code{#f}, for example when @var{url} contains a tag reference.
>
> Hmm, IIRC, tags in svn are mutable, no?

Disclaimer: prior to this patch, I knew nothing about SVN. So feel free
to take my answers with a grain of salt.

Now to answer your question, yes, they are mutable. But in practice,
altering tagged contents seems to be frowned upon in the
trunk-branch-tag trilogy.

> My recollection is that there’s no distinction between a directory, a
> branch, and a tag: tags and branches are just a copy (‘svn cp’) of a
> directory that can change over time.  Thus, you can’t rely on a tag as
> an unambiguous reference.
>
> Am I right?

You are certainly right, but I think this patch still makes sense for
projects that swear to never change tagged contents, which could
possibly be the case for most of the projects using SVN. Every now and
then, we will encounter a project that does modify such contents, but it
also currently happens with tarballs: sometimes, upstream modifies the
contents of a tarball without changing its name, inducing a hash
mismatch.

My concern here is that some Guix packages relying on `svn-fetch'
provide both a tag and a revision, which is redundant. We could get rid
of the tag, but the revision is not human-friendly.

Regards,
-- 
Nicolas Goaziou