RE : SVN 1.6: What is the maximum size for a commit?

[CHAZAL Julien <JU...@atos.net>]

Thanks a lot for you help.

My server is in a 32-bit mode. Anyway, I'll take a look for "LimitRequestBody" option in apache conf.

Regards.

________________________________________
De : Andy Levy [andy.levy@gmail.com]
Date d'envoi : vendredi 7 septembre 2012 17:52
À : CHAZAL Julien
Cc : users@subversion.apache.org
Objet : Re: SVN 1.6: What is the maximum size for a commit?

On Fri, Sep 7, 2012 at 11:12 AM, CHAZAL Julien <JU...@atos.net> wrote:
> Hi all,
>
> I manage a Subversion server (SVN 1.6.9, FSFS storage mode, set up on a
> Linux Suse Enterprise Edition) and I usually encounter a problem when my
> users commit a set of folders which the size is more than 4 GB.
>
> The error message that appears is "Revision file lacks trailing new line"
> (obtained with TortoiseSvn client, with https protocol). I know how to
> resolve this issue, but I wonder why Subversion doesn't allow commits
> greater than 4 GB.
>
> So, is there somebody that knows the size limit for a commit? Is it due to
> HTTPS protocol or due to Subversion 1.6?
>

It's possible you're running out of temp space on your server, or
Apache is limiting the size of the commit - I don't think it's
Subversion directly limiting you here. Look for a LimitRequestBody
directive in your Apache configuration and bump the size up, or if you
don't have the directive add it with a limit higher than 4GiB.

Is your server 32-bit or 64-bit? If 64-bit, are Apache & the
Subversion modules compiled for 32-bit or 64-bit? If it's all 32-bit,
I wonder if that's a factor as well.

The below disclaimer is meaningless on a public mailing list.

> ________________________________
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
> exclusif de ses destinataires. Il peut également être protégé par le secret
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
> pouvant être assurée sur Internet, la responsabilité du groupe Atos ne
> pourra être engagée quant au contenu de ce message. Bien que les meilleurs
> efforts soient faits pour maintenir cette transmission exempte de tout
> virus, l'expéditeur ne donne aucune garantie à cet égard et sa
> responsabilité ne saurait être engagée pour tout dommage résultant d'un
> virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail in
> error, please notify the sender immediately and destroy it. As its integrity
> cannot be secured on the Internet, the Atos group liability cannot be
> triggered for the message content. Although the sender endeavors to maintain
> a computer virus-free network, the sender does not warrant that this
> transmission is virus-free and will not be liable for any damages resulting
> from any virus transmitted.
________________________________


Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Re: RE : SVN 1.6: What is the maximum size for a commit?

[Andreas Mohr <an...@lisas.de>]

Hi,

On Mon, Sep 10, 2012 at 08:27:19AM +0000, CHAZAL Julien wrote:
> Thanks a lot for you help.
> 
> My server is in a 32-bit mode. Anyway, I'll take a look for "LimitRequestBody" option in apache conf.

Just to state the yet non-stated to make sure that matters are clear
(many people may easily be unaware of that):

a server being a 32bit OS should IN NO WAY result in I/O transfers
of a heavy-weight I/O software being limited to 32bit, too (well, ideally......).
That's what the difference between "64bit file I/O" and actual 64bit OS was
supposed to be for (the transition to "64bit file I/O" was made
quite a bit *before* actual 64bit OSes properly supporting 64bit *CPUs*
were commonplace).

IOW, this likely indicates that a 32bit type
(i.e., a type limited/adhering to system-width) is erroneously being used
somewhere within the transfer chain, rather than an actual 64bit type
(see various stdint.h implementations for specifics)
that's suitable for 64bit data transfers on a 32bit system as well.


So much for the theory - now as to whether SVN transfers
are supposed to qualify for "heavy-weight I/O"
(i.e. whether that is a valid sufficiently frequent use case on 32bit platforms),
that's obviously another matter ;)

Andreas Mohr

> ________________________________________
> De : Andy Levy [andy.levy@gmail.com]
> Date d'envoi : vendredi 7 septembre 2012 17:52
> À : CHAZAL Julien
> Cc : users@subversion.apache.org
> Objet : Re: SVN 1.6: What is the maximum size for a commit?

[...]

> Is your server 32-bit or 64-bit? If 64-bit, are Apache & the
> Subversion modules compiled for 32-bit or 64-bit? If it's all 32-bit,
> I wonder if that's a factor as well.

-- 
GNU/Linux. It's not the software that's free, it's you.