RE: Wait for hours when commit or update a larger .unity file

> -----Original Message-----
> From: Chao.Guan [mailto:mr_kernel_at_163.com]
> Sent: donderdag 16 oktober 2014 03:35
> To: 'Branko Čibej'; users_at_subversion.apache.org
> Subject: RE: Wait for hours when commit or update a larger .unity file
>
> > -----Original Message-----
> > From: users-return-22344-mr_kernel=163.com_at_subversion.apache.org
> > [mailto:users-return-22344-mr_kernel=163.com_at_subversion.apache.org]
> On
> > Behalf Of Branko ?ibej
> > Sent: Wednesday, October 15, 2014 1:07 PM
> > To: users_at_subversion.apache.org
> > Subject: Re: Wait for hours when commit or update a larger .unity file
> >
> > On 15.10.2014 05:03, Chao.Guan wrote:
> > > Hello,
> > >
> > > I have a problem with using SVN.
> > >
> > > Here is the situation:
> > > I am a Unity3D user, and I have to wait for hours when I commit or
> > > update a very large * .unity file with SVN. The file is about 100M or so.
> >
> > That's strange; 100M isn't really "huge" that it should take hours to commit.
> >
> > > Can you guys let me what happened when a very large file is committed
> > > or updated?
> > > I will appreciate it very much if there are any great suggestions.
> >
> > First of all we need to know which version of Subversion you're using
> (client and
> > server), how your server is set up and how you're accessing it (http:// vs.
> svn://,
> > for example), client and server platform; and not least, the quality of your
> > network connection to the server.
> >
>
> I am sorry. I thought it was the common behavior for SVN released from
> different version.
>
> Actually, I am using tortoiseSVN 1.6.16, Build 21511 - 64 Bit on my Windows 7
> SP1, and I am not sure if this is a bug for SVN.

Any reason why you can't use a currently supported Subversion release? (1.7 and later).

The working copy library was mostly rewritten between 1.6 and 1.7, which makes your tests unlikely to apply to any current version.

When working on the working copy library I found cases where just locking before the operation took minutes on <= 1.6, while it is milliseconds in 1.7+. And that is before the actual operation (update/commit) even starts to do any work.

>
> And we use it on LAN, but we have about 100 engineers work for our project.
> Maybe that's a factor.

So you use a network disk instead of a local harddisk?

That would be something to mention in your first mail on performance subjects, as that makes all the difference.

        Bert

>
> I was thinking, maybe I can find out what is happening when I am committing
> or updating, then I can solve the problem by setting the file format of *.unity
> file or some other working around. Can you give me some hints? Which
> factor takes the most time?
>
> > Further questions may follow after that. :)
> >
>
>
> Thanks, Chao
>
>
Received on 2014-10-16 10:04:04 CEST