You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mohsin <mo...@gmail.com> on 2014/12/10 21:15:13 UTC

SVN Issue On Solaris OS

Good Day SVN Experts,

I recently upgraded svn v 1.8.9 to v 1.8.10 from Linux OS to Solaris OS.
Linux machine was desktop machine with low specs and Solaris machine is
T1000 server class machine. Now issue we faced is when we start rsync from
Solaris machine disk usage of machine goes to 100 % and machine goes to un
responsive mode while on previous Linux machine we have not faced any issue.
This thing is very strange for me because svn should work properly on
Solaris machine because that machine have better specs but result is
opposite. One thing which we have changed on Solaris machine is the
structure of repositories; on previous server path for repos was /u/ ,
/us/local , /usr/wb etc but on new Solaris server we have merged all
repositories on one path which is /u/ should this can cause the disk usage
to 100 % because now data is fetching from one path; or there is another
issue. Can someone shed light on this issue.


Regards
Mohsin Abbas



--
View this message in context: http://subversion.1072662.n5.nabble.com/SVN-Issue-On-Solaris-OS-tp191199.html
Sent from the Subversion Dev mailing list archive at Nabble.com.

Re: SVN Issue On Solaris OS

Posted by Mohsin <mo...@gmail.com>.
Done. Posted to users@ 



--
View this message in context: http://subversion.1072662.n5.nabble.com/SVN-Issue-On-Solaris-OS-tp191199p191204.html
Sent from the Subversion Dev mailing list archive at Nabble.com.

Re: SVN Issue On Solaris OS

Posted by Mark Phippard <ma...@gmail.com>.
That is not how this works.  Please post to users@

Thanks

On Wed, Dec 10, 2014 at 3:59 PM, Mohsin <mo...@gmail.com> wrote:

> You are right I have posted here because dev have more knowledge as
> compared
> to users.
>
>
>
> --
> View this message in context:
> http://subversion.1072662.n5.nabble.com/SVN-Issue-On-Solaris-OS-tp191199p191201.html
> Sent from the Subversion Dev mailing list archive at Nabble.com.
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: SVN Issue On Solaris OS

Posted by Mohsin <mo...@gmail.com>.
You are right I have posted here because dev have more knowledge as compared
to users.



--
View this message in context: http://subversion.1072662.n5.nabble.com/SVN-Issue-On-Solaris-OS-tp191199p191201.html
Sent from the Subversion Dev mailing list archive at Nabble.com.

Re: SVN Issue On Solaris OS

Posted by Mark Phippard <ma...@gmail.com>.
This belongs on the users@ list.  It is not about the development of
Subversion.

When you repost to users@, you should probably explain why you think rsync
bringing your disk usage to 100% is a question for the Subversion community
to answer.



On Wed, Dec 10, 2014 at 3:15 PM, Mohsin <mo...@gmail.com> wrote:

> Good Day SVN Experts,
>
> I recently upgraded svn v 1.8.9 to v 1.8.10 from Linux OS to Solaris OS.
> Linux machine was desktop machine with low specs and Solaris machine is
> T1000 server class machine. Now issue we faced is when we start rsync from
> Solaris machine disk usage of machine goes to 100 % and machine goes to un
> responsive mode while on previous Linux machine we have not faced any
> issue.
> This thing is very strange for me because svn should work properly on
> Solaris machine because that machine have better specs but result is
> opposite. One thing which we have changed on Solaris machine is the
> structure of repositories; on previous server path for repos was /u/ ,
> /us/local , /usr/wb etc but on new Solaris server we have merged all
> repositories on one path which is /u/ should this can cause the disk usage
> to 100 % because now data is fetching from one path; or there is another
> issue. Can someone shed light on this issue.
>
>
> Regards
> Mohsin Abbas
>
>
>
> --
> View this message in context:
> http://subversion.1072662.n5.nabble.com/SVN-Issue-On-Solaris-OS-tp191199.html
> Sent from the Subversion Dev mailing list archive at Nabble.com.
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/