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

Previous Next

Full log

Message #17 received at 71371 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 71371 <at> debbugs.gnu.org, Josselin Poiret <dev <at> jpoiret.xyz>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>,
 Florian Pelz <pelzflorian <at> pelzflorian.de>, Ricardo Wurmus <rekado <at> elephly.net>,
 Christopher Baines <guix <at> cbaines.net>, Matthew Trzcinski <matt <at> excalamus.com>
Subject: Re: [bug#71371] [PATCH] gnu: svn-fetch: Make revision field optional.
Date: Wed, 05 Jun 2024 22:44:08 +0200

Hello,

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

> Nicolas Goaziou <mail <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.