Re: tarballs - why in SVN?
"Eddy Petriÿor" <eddy.petrisor@gmail.com> writes:
>> committing / uploading orig.tar.gz is done via
>> 'svn import svn+ssh://costa.debian.org/...'
>
> AFAIK this does not happen by default, does it?
Well, I don't understand what you mean with that. It is available by
default in all svn installations I've seen so far.
>> 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.
I think it's neglectible. And after all, uploading a new tarball doesn't
happen that often.
>> 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
Really? AFAIK this is done via mod-subversion, an apache module. Getting
the most recent version of a given working copy should be rather
cheap, no? If it is, I'm happy to be corrected, but even then its a
design issue of mod-subversion.
> - 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
Err, that a characteristic of a VCS. Yes.
I don't really see a use case where it was necessary to checkout the
complete directory where the tarballs are located in.
Afterall, advocates of patch systems are in fact using svn as
distributed versioned filesystem. I think placing upstream tarballs
is in principle not different from using svn to hold patch
files. Besides the filesize of course.
> - 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
Really? have you measured that?
> - 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
> filtered out.
If this is really a concern, we would have to ban full sources from
svn as well. I object.
>> 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
placing them in svn is not dedicated? How is this an advantage?
> + tarballs which entered the official mirrors can be deleted from
> + our space
true
> + no legal issues hard to solve (yes, I pulled that out of my hat
> + :-P )
hm. you mean when we are forced to remove source for legal issues. How
often did this happen in the past? And, see above, this would require
removing all sources from the repository anyway
> + faster downloads
Really?
> + 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,
I don't understand this argument. Why that?
> we can create simple and intuitive scripts (I don't like the extra
> chars in websvn URLs)
aha. You are talking about the '\?do=file' suffix in the end?
> - 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.
Again, I don't see any common usecase where it should be necessary to
have a checkout of the tarballs directory.
In the end, I don't really mind if all ppl insist in moving the
tarballs to an ftp site, as long as it's easy for members of the games
team to upload tarballs to. However, I'm still not convinced that this
approach has any advantages to the current situation (besides of
slightly more load on costa).
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reply to: