Re: tarballs - why in SVN?
On 14/08/06, Reinhard Tartler <siretart@tauware.de> wrote:
"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 thought you typed svn-import :-D
But still why would you want to place the orig *tarballs* in SVN, is
beyond my understanding. IMO there is no real benefit and doing it
forces people to use SVN in a broken way and make people dependant on
knowing project culture, while using a plain webserver is highly
intuitive.
>> 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.
No, only at every upstream release :-P .
>> 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.
That *needs* to go through the SVN filesystem and detect the contents
of the current copy (I know the older snapshots are diffs to the most
recent one, so is optimised to get the most recent stuff), but that
involves an extra hop, the svn library, instead of just taking the
thing directly from the filesystem, where there is no extra
processing.
> - 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.
Not if we talk about CVS :-D
I don't really see a use case where it was necessary to checkout the
complete directory where the tarballs are located in.
There is no such case, but that is the usual workflow with a VCS. I
did it without realising I could have downloaded the file via the web
interface. But, still, why add an extra hop when we can use plain
HTTP/FTP?
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.
You've hit the nail, the size is a factor and it affects svn overall
persormance. As the time passes the repo becomes bigger (I don't know
if they are using fsfs on alioth, but I think I recall it did), thus
it will be more sluggish.
> - 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?
Is common sense. With downloads over websvn you have an extra layer (or two):
websvn: client->apache(websvn)->svn libs->filesystem
plain http: sclient->apache->filesystem
> - 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.
It could be, but the lower the number of such possible causes are, the
less chanches are this will happen.
>> 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?
Because is optimised for file transfer of plain files and serving
plain files, in contrast to keeping history of some files which will
NOT change and using the storing stuff only.
> + 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
Yes, but storing them outside will generate less work, if that
happens. Also note that not many of our packages have the full source
in SVN, so in conjunction to this, we would be safe from this eventual
trap.
> + faster downloads
Really?
See the layers placed on a http download and a http download from
websvn interface. Is common sense.
> + 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?
Because many will prefer to provide the sources from upstream http/ftp
or even the official Debian mirrors since they are a dedicated
protocol for such a thing, will not need the extra step of svn
importing, and many do not install a websvn interface just to be able
to download sources from svn from a http location since is just plain
stupid to do that (why add unnecessary extra steps?).
> 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?
that. too
> - 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.
you are too much confined in the current set up and you are taking for
granted that it will always work.
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).
I don't understand this last statement. Is costa running http/ftp
services and haydn the svn and websvn? Or? In any case, the overall
work should decrease (see arguments above).
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: