On 10/30/13 09:56, Stefan Sperling wrote:
I believe it's the stupid code replaced below, which I wrote in r880420.
Because of it we end up setting perms based on umask upon every commit,
and end up expanding restrictive file permissions.
This patch should fix the problem.
Indeed, the file
Hi,
I still feel 1.8.3 subversion as a step backwards in terms of speed,
compared to the pre-sqlite era (and it seems there are some problems
with sqlite 3.8 (even with 3.8.1), so the following was made with 3.7.17).
My wc.db is 3.1G, completely fits into (and is in) memory, so sqlite
disk
Hi,
On 10/24/13 22:05, Branko Čibej wrote:
As Thorsten has pointed out, this is a different case. BTW, I have a
similar solution, like contrib/asvn, but the current operation of svn
makes it impossible/very hard to make it work, because it screws up
real file permissions on each commits.
Yes,
Hi,
I store OS images in svn, so I need to record file permissions and
ownership. For this, I use properties.
But svn changes real file permissions:
# ls -l fstab
-rw-r--r-- 1 root wheel 230 Oct 22 2011 fstab
# svn pg file:permissions fstab
mode=33188 user=(0) group=(0)
# chmod 600 fstab
#
On 06/25/12 15:04, Philip Martin wrote:
Attila Nagy b...@fsn.hu writes:
I suffer from the slowness of svn rm since the upgrade to 1.7 from
1.6, but I couldn't find the time to profile it until now.
My setup is: FreeBSD 9-STABLE/amd64 with zfs, eight fast cores, SAN,
32 GiB of RAM.
Versions
(see my other mail)
from 40 minutes to 3 seconds...
yay, \o/
On 06/25/12 14:57, Mark Phippard wrote:
Could you try building trunk? I believe these issues have been resolved or at
least improved. It would be good to see how much.
Sent from my iPhone
On Jun 25, 2012, at 8:36 AM, Attila Nagy b
On 06/25/12 16:41, Stefan Sperling wrote:
On Mon, Jun 25, 2012 at 04:33:50PM +0200, Attila Nagy wrote:
ps: I hope trunk is stable enough now for general daily usage... :)
No, not yet. Unless you want to help out with development and/or testing
please do not run trunk code until released
Hi,
I'm using subversion 1.7.2 with serf 1.0.0 on FreeBSD to check out
http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller, but it
fails at:
bootvm# svn co http://svn.freebsd.org/base/stable/9/sys/dev/usb/controller
Acontroller/atmegadci_atmelarm.c
Acontroller/at91dci.c
A
Hi,
I have a local working copy with some files and directories:
# find . | wc -l
1255817
wc.db is currently 1.1 GiB:
# du -hsA wc.db
1.1Gwc.db
I've started an svn rm * in one directory and after 20 minutes it's
still running. The directory is not quite large, it contains 153 small
text
On 11/16/11 18:40, Philip Martin wrote:
Attila Nagyb...@fsn.hu writes:
I use pysvn for this and basically the code looks like this (in python):
def update_perms():
for path in propchg:
proplist = svn.propget('file:permissions', path)
if not os.path.islink(path) and
On 10/27/11 14:57, Mark Phippard wrote:
On Thu, Oct 27, 2011 at 8:12 AM, Attila Nagy b...@fsn.hu
mailto:b...@fsn.hu wrote:
ZFS.
It it worth to make benchmarks with this WC with 1.6 and 1.7? I so,
I can try to find the time for it.
There are some pretty easy to run benchmarks you
On 10/26/11 15:37, Philip Martin wrote:
Attila Nagyb...@fsn.hu writes:
I'm trying to update a working copy of some tens of GBs with svn 1.7.1
Did you upgrade with 1.7.0 or 1.7.1?
I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
currently using.
The upgrade took nearly one
On 10/27/11 13:47, Mark Phippard wrote:
On Thu, Oct 27, 2011 at 4:47 AM, Attila Nagy b...@fsn.hu
mailto:b...@fsn.hu wrote:
On 10/26/11 15:37, Philip Martin wrote:
Attila Nagyb...@fsn.hu mailto:b...@fsn.hu writes:
I'm trying to update a working copy of some tens of GBs with svn
On 10/27/11 12:58, Philip Martin wrote:
Attila Nagyb...@fsn.hu writes:
On 10/26/11 15:37, Philip Martin wrote:
Attila Nagyb...@fsn.hu writes:
I'm trying to update a working copy of some tens of GBs with svn 1.7.1
Did you upgrade with 1.7.0 or 1.7.1?
I've upgraded the WC with 1.7.0,
On 10/27/11 14:13, Philip Martin wrote:
Mark Phippardmarkp...@gmail.com writes:
I would imagine svn upgrade is almost entirely writes and I recall it does
quite a few transactions. So couldn't the linear slow down just be based on
the growth in the amount of bytes that are written to disk
Hi,
I'm trying to update a working copy of some tens of GBs with svn 1.7.1
(upgraded the WC to the new -sadly much slower- format) and always get this:
$ svn up
Updating '.':
Skipped 'mail/20110624/usr/local/etc/blacklist' -- Node remains in conflict
svn: E235000: In file
On 10/26/11 15:31, Mark Phippard wrote:
On Wed, Oct 26, 2011 at 5:01 AM, Attila Nagyb...@fsn.hu wrote:
I'm trying to update a working copy of some tens of GBs with svn 1.7.1
(upgraded the WC to the new -sadly much slower- format) and always get this:
Is your WC on a network drive? That is
17 matches
Mail list logo
