> On 9 Aug 2021, at 11:48, Daniel Sahlberg wrote:
>
> Den lör 17 juli 2021 kl 15:02 skrev Attila <mailto:atiw...@gmx.net>>:
> On 14 Jul 2021, at 21:42, Nathan Hartman <mailto:hartman.nat...@gmail.com>> wrote:
>>
>> On Tue, Jul 13, 2021 at 5:49 P
On 14 Jul 2021, at 21:42, Nathan Hartman wrote:
>
> On Tue, Jul 13, 2021 at 5:49 PM Attila <mailto:atiw...@gmx.net>> wrote:
>>
>> Hi
>>
>> I have a problem getting the svn log in a branch after sync-merging a commit
>> from trunk.
>> Th
what related hits:
https://issues.apache.org/jira/browse/SVN-4856
https://issues.apache.org/jira/browse/SVN-4711
But I do'nt use the --search parameter.
Is this a bug or are there any suggestions how to solve this problem?
Thanks,
Attila
ng together with
a bunch of computer scientists. These are not computer savy people!
I'm glad we are using any SCM in the first place and not some Dropbox
with zip files or something.
Seem's like I have to think about changing our workflow..
Thanks a lot!
Attila Kinali
--
for this?
Thanks and chocolaty greetings!
Attila Kinali
--
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
/apache/include
and now compiles without error
thank you for your help.
Attila
for clarifying this.
Attila
\
--with-apr-util=/path/to/my/folder/apr-util/bin/apu-1-config \
--enable-ssl \
--enable-http \
--enable-so \
--enable-unique-id \
--enable-rewrite \
--enable-deflate \
--enable-dav \
--enable-ldap \
--with-ldap \
--enable-authnz-ldap
which httpd version sould i use?
thanks.
Attila Soki
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
On Fri, 3 Feb 2012 10:12:08 -0500
Nico Kadel-Garcia nka...@gmail.com wrote:
On Fri, Feb 3, 2012 at 10:01 AM, Attila Kinali att...@kinali.ch wrote:
Other than that issue, subversion is GPL and it's restrictions apply.
You can find ample descriptions how these apply to comercial enviroments
Protugisisch wirst
du leider nicht viel erfolg haben.
Other than that issue, subversion is GPL and it's restrictions apply.
You can find ample descriptions how these apply to comercial enviroments.
Just google for them.
今度英語で書いてください
Attila Kinali
--
The trouble with you, Shev
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
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
/to/deleted/d...@41 works fine.
Same is true for svn ls, using -rnum in svn:externals properties
and probably a few other places as well.
I had a look at the issue tracker but couldnt find any related entry.
Attila Kinali
--
If you want to walk fast, walk alone.
If you want
it
tries to move it. Which windows will refuse because the file is on
a remote file server.
Can anyone confirm this bug?
Thanks in advance
Attila Kinali
--
If you want to walk fast, walk alone.
If you want to walk far, walk together.
-- African proverb
29 matches
Mail list logo
