Re: tarballs - why in SVN?
On 14/08/06, Reinhard Tartler <firstname.lastname@example.org> wrote:
"Eddy Petriÿor" <email@example.com> writes:
>> I'd even recommend to point them to the alioth svn interface, just as
>> the link above. Its more or less plain http after all.
> Yes, but still, IMHO, it doesn't make sens to load the SVN server with
> orig tarballs.
committing / uploading orig.tar.gz is done via
'svn import svn+ssh://costa.debian.org/...'
AFAIK this does not happen by default, does it?
I don't think that costa has problem with ssh uploads via subversion.
Otherwise I think the alioth admins would say something about that.
Yes, but it might lead to CPU hogging, svn+transport being more CPU
hungry than plain http/ftp servers, AFAIK.
Where else should we upload the orig.tar.gz then? The current place
has these advantages:
+ obvious where to place them
+ you see in svn log who uploaded what file when
- I can't use svn to get a certain tarball since I would pull the
whole dir, thus I must use http downloading, which in turn uses svn
- the directory will become bigger and bigger and bigger and bigger by
time, with new lots and lots and lots ... of upstream tarballs and
- all files will remain in the SVN repository forever even if "svn
del"-eted since they are not actually deleted
- svn is not a ftp server and using "svn over http" (as happens when
downloading via the websvn interface) is slower than plain ftp of http
- in the remote and improbable future when one file will be decided to
be non-free (see boson recent history) and will have to be removed
from the repo we will have to ask alioth admins to reimport a filtered
svn dump from which the revision which added the infringing file was
If we don't upload to svn, where should we upload the tarballs then?
Quoting myself in the initial mail: "I would [...] suggest moving all
of them in the web sapace or the FTP space of the project."
+ is a dedicated place
+ tarballs which entered the official mirrors can be deleted from our space
+ no legal issues hard to solve (yes, I pulled that out of my hat :-P )
+ faster downloads
+ it is more likely to have real URL support in svn-buildpackage before svn URIs
+ until svn-bp:origUrl properties are supported by svn-buildpackage,
we can create simple and intuitive scripts (I don't like the extra
chars in websvn URLs)
- one must use two protocols instead of, well... two :-P , if the
person does not have already a checkout of the tarballs directory,
case in which it can use only one (svn up), which, in turn can bring
unwanted tarballs, too.
"Imagination is more important than knowledge" A.Einstein