Advice for better SVN

[????]

I'm a programmer who very love SVN.
When I commit works through Internet, send files one by one always very slow.
Why don't archive all files as a single Zip file, and send the only file to SVN 
server? (as like Git)
Hope to help.
Thanks.

Re: Advice for better SVN

[Stefan Hett]

On 11/24/2016 12:19 PM,  wrote:

I'm a programmer who very love SVN.
When I commit works through Internet, send files one by one always 
very slow.
Why don't archive all files as a single Zip file, and send the only 
file to SVN server? (as like Git)

Hope to help.
Thanks.



You'd determine the cause of the slowness in your case. For once: Make 
sure you are using an appropriate protocol (http/https or svn(+ssh) 
rather than the file-protocol).
SVN transmissions are quite optimized and also compressed to some point 
which is in certain cases superior over compressing all files and 
transmit them over the wire... Certainly there are cases where I could 
envision that a single compressed archive might be significant faster 
than the current approach, but these are not for regular operations 
you'd usually do (like a fresh checkout of a repository or committing 
large duplicated files).


--
Regards,
Stefan Hett

Re: Advice for better SVN

[Nico Kadel-Garcia]

On Thu, Nov 24, 2016 at 6:19 AM, 蝌蚪 <25441...@qq.com> wrote:
> I'm a programmer who very love SVN.
> When I commit works through Internet, send files one by one always very
> slow.
> Why don't archive all files as a single Zip file, and send the only file to
> SVN server? (as like Git)
> Hope to help.
> Thanks.

Because Subversion doesn't normally send files, which could get very
bulky and very expensive to compare and verify on the other end. It
sends the *changes* in the files. This is much smaller, and safer if
there are "svn:keywords" enabled which may differ if checked out on a
server and checked out on a client.

Subversion, and most source control systems, does not keep complete
distinct copies of the files. They store the *changes* between file
revisions. including the original commit, and assemble the end file
from all the changes. It's one of the reasons anything that changes
history can be so dangerous.

Re: Advice for better SVN

[Pavel Lyalyakin]

On Thu, Nov 24, 2016 at 3:43 PM, Stefan Hett  wrote:
>
> On 11/24/2016 12:19 PM, 蝌蚪 wrote:
>>
>> I'm a programmer who very love SVN.
>> When I commit works through Internet, send files one by one always very slow.
>> Why don't archive all files as a single Zip file, and send the only file to 
>> SVN server? (as like Git)
>> Hope to help.
>> Thanks.
>>
>>
>>
> You'd determine the cause of the slowness in your case. For once: Make sure 
> you are using an appropriate protocol (http/https or svn(+ssh) rather than 
> the file-protocol).

file:// protocol? How would OP access a server on the Internet through file://?

--
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: Advice for better SVN

[Branko Čibej]

On 24.11.2016 15:00, Pavel Lyalyakin wrote:
> On Thu, Nov 24, 2016 at 3:43 PM, Stefan Hett  wrote:
>> On 11/24/2016 12:19 PM, 蝌蚪 wrote:
>>> I'm a programmer who very love SVN.
>>> When I commit works through Internet, send files one by one always very 
>>> slow.
>>> Why don't archive all files as a single Zip file, and send the only file to 
>>> SVN server? (as like Git)
>>> Hope to help.
>>> Thanks.
>>>
>>>
>>>
>> You'd determine the cause of the slowness in your case. For once: Make sure 
>> you are using an appropriate protocol (http/https or svn(+ssh) rather than 
>> the file-protocol).
> file:// protocol? How would OP access a server on the Internet through 
> file://?

NFS and CIFS work just fine over the internet, though I admit you'd have
to be a bit of a masochist to try that.


Back to the original topic: Subversion's deltas are, for most practical
applications, quite a bit more efficient than sending tarballs of whole
files would be ... and the ZIP format is significantly less efficient
than compressed TAR.

-- Brane

Re: Advice for better SVN

[Nico Kadel-Garcia]

On Thu, Nov 24, 2016 at 9:08 AM, Branko Čibej  wrote:
> On 24.11.2016 15:00, Pavel Lyalyakin wrote:

>>> You'd determine the cause of the slowness in your case. For once: Make sure 
>>> you are using an appropriate protocol (http/https or svn(+ssh) rather than 
>>> the file-protocol).
>> file:// protocol? How would OP access a server on the Internet through 
>> file://?
>
> NFS and CIFS work just fine over the internet, though I admit you'd have
> to be a bit of a masochist to try that.

Been there, done that. CIFS is *not*, *not*, *not* your friend for
Subversion working copies, nor for file:// server access. It's a very
"chatty" protocol. NFS tends to be far faster and more robust, with
the exception of NFS servers getting confused about whether clients
are still connected.

> Back to the original topic: Subversion's deltas are, for most practical
> applications, quite a bit more efficient than sending tarballs of whole
> files would be ... and the ZIP format is significantly less efficient
> than compressed TAR.
>
> -- Brane
>

Re: Advice for better SVN

[Eric Johnson]

On Nov 24, 2016, at 4:33 AM, 蝌蚪 <25441...@qq.com> wrote:

I'm a programmer who very love SVN.
When I commit works through Internet, send files one by one always very
slow.
Why don't archive all files as a single Zip file, and send the only file to
SVN server? (as like Git)
Hope to help.
Thanks.



Also, might help to investigate which version of SVN you're using on both
the client and the server. Each release tends to bring some performance
improvements.

It may also be that the server is mis-configured, and performing slowly.
More details would help diagnose the specific issue.

Eric