Ivan Zhakov wrote:
> On 7/9/07, Blair Zajac <blair@orcaware.com> wrote:
>> Ivan Zhakov wrote:
>> > On 7/8/07, Ivan Zhakov <chemodax@gmail.com> wrote:
>> >> On 7/8/07, D.J. Heap <djheap@gmail.com> wrote:
>> >> > On 7/7/07, Ivan Zhakov <chemodax@gmail.com> wrote:
>> >> > [snip]
>> >> > > And of course primary question: Does it work without my patch?
>> >> Because
>> >> > > these failures can be related to new txn generation code,
>> >> committed by
>> >> > > Blair in r25430.
>> >> > >
>> >> >
>> >> >
>> >> > I'm building with trunk r25679 and after backing out r25650, the
>> >> > fs-test.exe passes all tests again. So, either the patch is
>> bringing
>> >> > out some lurking problem, or it is affecting the fs stuff in some
>> way
>> >> > I can't seem to figure out.
>> >> >
>> >> It seems I found way to reproduce problem even without my patch. Many
>> >> fs-test will fail on Windows if you just remove time part from
>> >> generated transaction name in fs_fs. See patch:
>> >>
>> >> Index: subversion/libsvn_fs_fs/fs_fs.c
>> >> ===================================================================
>> >> --- subversion/libsvn_fs_fs/fs_fs.c (revision 25654)
>> >> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
>> >> @@ -3195,7 +3195,7 @@
>> >> *p = '-';
>> >>
>> >> process_id = getpid();
>> >> - now = apr_time_now();
>> >> + now = 0; /* It's for testing purposes only! should
>> apr_time_now(). */
>> >>
>> >> unique_basename = apr_psprintf(pool, "%s-%05d-%" APR_TIME_T_FMT,
>> >> hostname_str, process_id, now);
>> >> Index: subversion/libsvn_subr/utf.c
>> >> ===================================================================
>> >> --- subversion/libsvn_subr/utf.c (revision 25654)
>> >> +++ subversion/libsvn_subr/utf.c (working copy)
>> >> @@ -253,7 +253,7 @@
>> >> pool = apr_hash_pool_get(xlate_handle_hash);
>> >>
>> >> /* Try to create a handle. */
>> >> -#if defined( WIN32)
>> >> +#if 0
>> >> apr_err = svn_subr__win32_xlate_open(&handle, topage, frompage,
>> pool);
>> >> #elif defined(AS400)
>> >> apr_err = apr_xlate_open(&handle, (int)topage, (int)frompage,
>> pool);
>> >>
>> >> So it seems the problem of my patch that it made running Subversion
>> >> faster and we got two transactions in the same time :)
>> >>
>> >> Now I'm trying to figure out why this transaction generation code
>> >> fails on Windows.
>> >>
>> > It seems I understand what is happen here.
>> > Before r25430 we've been generated transaction named
>> > "<rev>-<uniquifier>". After r25430 we tried to guarantee transaction
>> > names to be unique and added hostname, pid and time to transaction
>> > name. And for optimization we removed revision number from txn name.
>> > So we got "<hostname>-<pid>-<time>-<uniquifier>" txn names.
>> >
>> > Looks good, but bad news that this form of txn names isn't guarantee
>> > to be unique. At least on Windows, where apr_time_now() could return
>> > the same time for different transactions.
>>
>> How could that happen? Isn't the resolution of the time in microseconds?
> No, it isn't. On Windows apr_time_now() using GetSystemTime(). In
> returned in microseconds, but precision is approximately 10
> milliseconds.
> http://lists.boost.org/boost-users/2004/05/6635.php
>
>
>>
>> > And we are fail because fsfs assumes that transaction names unique
>> > between revisions! So it MUST include revision number.
>> >
>> > So we have to problems:
>> > 1. transaction names still isn't guaranteed to be unique
>> > 2. fsfs depends that transaction names unique between revisions, i.e.
>> > include revision number.
Actually, this won't fix the problem if you have two transaction started on the
same revision.
>>
>> The real solution, which I need to implement, is to add to fsfs a serial
>> transaction number, much like BDB does. This will make the transaction
>> names much shorter, which is a good thing.
>>
> Agreed. Do you have plans to do this? I really don't like that Windows
> build slave is failing now.
Yes, I am going to work on it.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 9 19:20:38 2007