roxen.lists.roxen.general

Subject Author Date
Re: 50MB binary blob in Roxen CVS? Martin Bähr <mbaehr[at]email[dot]archlab[dot]tuwien[dot]ac> 17-03-2009
On Tue, Mar 17, 2009 at 08:21:01AM +0100, Peter Ohlerich wrote:
> >> Excuse me for asking, but is including a 50MB Yahoo UI tar.gz blob
> >> directly into Roxen CVS a Good Thing (tm)?
> At this point the problem is in my opinion not the question wether it
> is good or not. The problem at our site is that the users do exactly
> this (uploading movies, presentations or sounds). I have several
> multi-100-MB files in the CVS.

those are two unrelated issues.
the first concerns the question whether the roxen source should contain
an archive with yet more source from elsewhere, which potentially messes
up the developers working with the roxen source (and it especially
interferes with importing cvs into distributed version control tool
where every user would be forced to download that archive.

your question is about wheter cvs is suitable to store large blobs of
non-text data in general.

i am certainly all for having everything in one place. if your users
need multi-100-MB files then so be it.

if there is an actual problem storing those in cvs (is it faster to
upload them outside of cvs?) then my suggestion would be that, since cvs
does not make binary diffs anyways, roxen cms could just bypass cvs for
any large binary files and store them seperately, while in cvs only
having a small text file with a link to the real file. so you would
still have versioning, because every new version would just get a new
link.

the actual problem you are seeing however is probably related to
blocking uploads, i don't know if cvs is the cause of that, and how it
can be improved.

btw, sTeam hasa 20MB upload limit for the same reason. uploads block to
long. in sTeams case the data is written to a database, with is another
debate regarding storing large blobs inside.

greetings, martin.
-- 
cooperative communication with sTeam      -     caudium, pike, roxen and unix
offering: programming, training and administration   -  anywhere in the world
--
pike programmer   working in china                      community.gotpike.org
unix system-      iaeste.(tuwien.ac|or).at                     open-steam.org
administrator     caudium.org                                    is.schon.org
Martin Bähr       http://www.iaeste.or.at/~mbaehr/