On 28.05.2013 15:24, Tobias Bading wrote:
> On 28.05.2013 15:15, Philip Martin wrote:
>> Are you running some non-standard kernel?
>
> Depends on your definition of 'standard'. ;-)
> I'm using the default kernel linux-image-2.6.32-46-generic from the
Ubuntu Lucid repositories.
Harmless little j
On 28.05.2013 15:15, Philip Martin wrote:
Are you running some non-standard kernel?
Depends on your definition of 'standard'. ;-)
I'm using the default kernel linux-image-2.6.32-46-generic from the
Ubuntu Lucid repositories.
Tobias Bading writes:
> Did you run the tests on Ubuntu 10.04 on an ext3 or ext4 filesystem?
> On ext3 you might not encounter this problem because ext3 only has a
> timestamp resolution of a second, thus you don't enter the
> "if(finfo.mtime % APR_USEC_PER_SEC)" block in
> svn_io_sleep_for_times
Branko Čibej writes:
> What we /should/ do is create a tempfile and keep changing and stat'ing
> it until its mtime changes. We could do this with an exponential backoff
> sleep, too. Then there would be no guesswork about the timestamp
> resolution of the WC file system.
>
> The problem is that
On 28.05.2013 14:31, Philip Martin wrote:
Tobias Bading writes:
b) '{ while true; do echo "">t; ls -l --full-time t; rm t; done; } |
uniq' prints exactly *two* lines per second, one every 0.5 seconds,
exact down to the millisecond.
I have an Ubuntu 12.04 machine and I see the expected behaviou
On 28.05.2013 12:54, Philip Martin wrote:
> Tobias Bading writes:
>
>> On 27.05.2013 16:12, Tobias Bading wrote:
>>> On 27.05.2013 16:01, Branko Čibej wrote:
Can you try this: run the following command for a couple of seconds, it
should give you an idea about the system clock precision.
Tobias Bading writes:
> b) '{ while true; do echo "" >t; ls -l --full-time t; rm t; done; } |
> uniq' prints exactly *two* lines per second, one every 0.5 seconds,
> exact down to the millisecond.
I have an Ubuntu 12.04 machine and I see the expected behaviour: lots of
different timestamps. I h
On 28.05.2013 12:54, Philip Martin wrote:
Tobias Bading writes:
On 27.05.2013 16:12, Tobias Bading wrote:
On 27.05.2013 16:01, Branko Čibej wrote:
Can you try this: run the following command for a couple of seconds, it
should give you an idea about the system clock precision.
{ while true; d
Tobias Bading writes:
> On 27.05.2013 16:12, Tobias Bading wrote:
>> On 27.05.2013 16:01, Branko Čibej wrote:
>>> Can you try this: run the following command for a couple of seconds, it
>>> should give you an idea about the system clock precision.
>>>
>>> { while true; do date '+%M:%S.%N'; done;
On 27.05.2013 16:12, Tobias Bading wrote:
On 27.05.2013 16:01, Branko Čibej wrote:
Can you try this: run the following command for a couple of seconds, it
should give you an idea about the system clock precision.
{ while true; do date '+%M:%S.%N'; done; } | uniq
Redirected to a file, I get ab
On 27.05.2013 16:01, Branko Čibej wrote:
Can you try this: run the following command for a couple of seconds, it
should give you an idea about the system clock precision.
{ while true; do date '+%M:%S.%N'; done; } | uniq
Redirected to a file, I get about 1250 unique timestamps per second,
nic
On 27.05.2013 15:40, Tobias Bading wrote:
> On 27.05.2013 12:43, Branko Čibej wrote:
>> On 27.05.2013 09:59, Tobias Bading wrote:
>>> Quick update:
>>> The problem is definitely timestamp related. "touch 3449_spurious"
>>> fixes a "corrupt" working copy, i.e. "svn status" and "svn diff" work
>>> pr
On 27.05.2013 12:43, Branko Čibej wrote:
On 27.05.2013 09:59, Tobias Bading wrote:
Quick update:
The problem is definitely timestamp related. "touch 3449_spurious"
fixes a "corrupt" working copy, i.e. "svn status" and "svn diff" work
properly afterwards. I'll try to figure out why my machine is
On 27.05.2013 09:59, Tobias Bading wrote:
> Quick update:
> The problem is definitely timestamp related. "touch 3449_spurious"
> fixes a "corrupt" working copy, i.e. "svn status" and "svn diff" work
> properly afterwards. I'll try to figure out why my machine is living
> in its own timeline. All I
Another update:
Tried to build against latest apr-1.4.6.tar.bz2 & apr-util-1.5.2.tar.bz2
instead of the older versions from the Ubuntu Lucid repositories. No
change :-(, i.e. the test fails with the original
svn_io_sleep_for_timestamps implementation.
Next update:
With a plain & simple
void
svn_io_sleep_for_timestamps(const char *path, apr_pool_t *pool)
{
apr_sleep(101);
}
in libsvn_subr/io.c the test is running slower, but works every time.
Quick update:
The problem is definitely timestamp related. "touch 3449_spurious" fixes
a "corrupt" working copy, i.e. "svn status" and "svn diff" work properly
afterwards. I'll try to figure out why my machine is living in its own
timeline. All I can say after reading just a few lines of python
Hi Branko & Philip,
thanks a lot for your hints. I've seen your mails only now on
http://mail-archives.apache.org/ and won't have access to my GNU/Linux machine
till Monday. Meanwhile I'm giving 1.8 RC2 a try on Mac OS Snow Leopard.
What do you mean by "sleep for timestamps disabled"? I didn't
Branko Čibej writes:
> On 24.05.2013 09:32, Tobias Bading wrote:
>> So, the update claims to have updated 3449_spurious to r2 and the
>> merge claims to have merged c4 into that file. As it turns out, both
>> claims seem correct. The contents of 3449_spurious look correct.
>> However, "svn status
On 24.05.2013 09:32, Tobias Bading wrote:
> Hi Philip,
>
> thanks for your suggestions. I tried to dig a little deeper... and now
> things are getting even more strange.
>
> First, I tried to delete everything after the "update -r2" from
> no_spurious_conflict so I could make a copy of the wc befor
Hi Philip,
thanks for your suggestions. I tried to dig a little deeper... and now
things are getting even more strange.
First, I tried to delete everything after the "update -r2" from
no_spurious_conflict so I could make a copy of the wc before the merge.
Guess what? Executing the "merge -c4
Tobias Bading writes:
> However, once I execute "[...]/svn revert -R .", "[...]/svn update",
> and "[...]/svn update -r2" in the working copy, the merge works just
> fine afterwards. And that "update -r2" is exactly what
> no_spurious_conflict in diff_tests.py does before the faulty merge, if
> I
Hello everyone,
I'm having a bit of trouble with subversion-1.8.0-rc2 on my Ubuntu Lucid
(x86_64) machine. "make check" or "./diff_tests.py 60" (in directory
subversion/tests/cmdline) fails with:
---
W: =
Expected '3449_spurious' an
23 matches
Mail list logo
