[svnbench] Revision: 1408161 compiled Nov 12 2012, 00:21:45 on x86_64-unknown-linux-gnu

[neels]

1.7.0@1181106 vs. trunk@1408153
Started at Mon Nov 12 00:25:11 UTC 2012

*DISCLAIMER* - This tests only file://-URL access on a GNU/Linux VM.
This is intended to measure changes in performance of the local working
copy layer, *only*. These results are *not* generally true for everyone.

Charts of this data are available at http://svn-qavm.apache.org/charts/

Averaged-total results across all runs:
---

Compare trunk@1408153 to 1.7.0
   Navg operation
 59/90.92|-11.975   TOTAL RUN
   3K/5300.72| -0.006   add
   118/180.56| -0.432   checkout
   472/721.32| +3.176   commit
 59/91.09| +0.023   copy
 59/90.78| -0.074   delete
   295/450.13| -5.027   info
   118/180.76| -0.939   merge
   3K/5160.82| -0.003   mkdir
   160/210.80| -0.002   propdel
   44K/6K0.76| -0.002   proplist
   45K/6K0.81| -0.002   propset
   3K/5910.75| -0.003   ps
   118/180.87| -0.001   resolve
   118/180.71| -0.068   resolved
  826/1260.71| -0.061   status
 59/90.86| -0.189   switch
  826/1260.66| -0.280   update
(legend: "1.23|+0.45" means: slower by factor 1.23 and by 0.45 seconds;
 factor < 1 and seconds < 0 means 'trunk@1408153' is faster.
 "2/3" means: '1.7.0' has 2 timings on record, the other has 3.)


Above totals split into separate x runs:


Compare trunk@1408153,5x5 to 1.7.0,5x5
   Navg operation
 20/30.94|-25.647   TOTAL RUN
   3K/4560.69| -0.007   add
 40/60.56| -1.151   checkout
   160/241.37| +9.822   commit
 20/31.34| +0.094   copy
 20/30.79| -0.179   delete
   100/150.12|-14.647   info
 40/60.78| -2.366   merge
   2K/4700.77| -0.003   mkdir
   160/200.78| -0.003   propdel
   41K/6K0.76| -0.002   proplist
   43K/6K0.81| -0.002   propset
   3K/5520.75| -0.003   ps
 40/60.84| -0.002   resolve
 40/60.68| -0.196   resolved
   280/420.70| -0.155   status
 20/30.91| -0.317   switch
   280/420.67| -0.697   update
(legend: "1.23|+0.45" means: slower by factor 1.23 and by 0.45 seconds;
 factor < 1 and seconds < 0 means 'trunk@1408153,5x5' is faster.
 "2/3" means: '1.7.0,5x5' has 2 timings on record, the other has 3.)

Compare trunk@1408153,100x1 to 1.7.0,100x1
   Navg operation
 20/30.92| -2.229   TOTAL RUN
   560/710.97| -0.001   add
 40/60.61| -0.074   checkout
   160/241.09| +0.175   commit
 20/30.92| -0.023   copy
 20/30.80| -0.022   delete
   100/150.47| -0.140   info
 40/60.71| -0.186   merge
   280/461.24| +0.004   mkdir
   2K/3370.73| -0.003   proplist
   1K/2730.74| -0.003   propset
   140/330.77| -0.003   ps
 40/60.88| -0.001   resolve
 40/61.11| +0.008   resolved
   280/420.79| -0.015   status
 20/30.58| -0.161   switch
   280/420.63| -0.100   update
(legend: "1.23|+0.45" means: slower by factor 1.23 and by 0.45 seconds;
 factor < 1 and seconds < 0 means 'trunk@1408153,100x1' is faster.
 "2/3" means: '1.7.0,100x1' has 2 timings on record, the other has 3.)

Compare trunk@1408153,1x100 to 1.7.0,1x100
   Navg operation
 19/30.92| -0.719   TOTAL RUN
 19/30.60| -0.017   add
 38/60.65| -0.027   checkout
   152/240.99| -0.009   commit
 19/30.99| -0.001   copy
 19/30.77| -0.006   delete
95/150.85| -0.009   info
 38/60.62| -0.082   merge
  703/1110.76| -0.002   proplist
  798/1260.75| -0.003   propset
 38/60.79| -0.002   ps
 38/60.90| -0.001   resolve
 38/60.71| -0.005   resolved
   266/420.74| -0.004   status
 19/30.67| -0.024   switch
   266/420.92| -0.004   update
(legend: "1.23|+0.45" means: slower by factor 1.23 and by 0.45 seconds;
 factor < 1 and seconds < 0 means 'trunk@1408153,1x100' is faster.
 "2/3" means: '1.7.0,1x100' has 2 timings on record, the other has 3.)



More detail:


Timings for 1.7.0,5x5
   Nmin max avg   operation  (unit is seconds)
  20  391.94  561.33  422.19  TOTAL RUN
  3K0.012.290.02  add
  400.025.812.64  checkout
 1601.53  160.96   26.55  commit
  200.190.490.28  copy
  200.741.240.85  delete
 1008.63   43.37   16.73  info
  406.40   21.02   10.61  merge
  2K0.010.660.01  mkdir
 1600.010.090.01  propdel
 41K0.010.690.01  proplist
 43K0.011.100.01  propset
  3K0.010.920.01  ps
  400.010.010.01  resolve
  400.450.960.60  resolved
 2800.202.360.53  status
  203.134.683.66  switch
 2800.257.022.13  update
--
Timings for trunk@1408153,5x5
   Nmin max avg   operation  (unit is seconds)
   3  374.15  440.59  396.54  TOTAL 

Re: Authz on Collection of Repositories

[Thomas Åkesson]

On 9 nov 2012, at 18:45, Ivan Zhakov wrote:

> On Thu, Nov 8, 2012 at 6:49 PM, Thomas Åkesson
>  wrote:
>> 
>> Parentpath on /svn/ and Satisfy Any:
>> 
>> - Access without auth displays repositories with anonymous access, auth is 
>> not requested.
>> - Access with auth displays filtered list. Works well when browser has 
>> previously
>> been on an authenticated path. This is the situation when Satisfy Any and 
>> filtered
>> Collection of Repositories does not work well.
> That's why mixing anonymous and authenticated access is not good thing.

Yes, I am just trying to cover all bases including the possibility that people 
are depending on the inconsistency that we are addressing.

> 
>> - Did a test with AuthzSVNAnonymous Off, which gave the quite surprising 
>> result
>> that all content was listed both on Collection of Repositories and within the
>> repositories. I doubt this is the intended behaviour?!?
> I agree, this is really strange behavior. Could you check this
> behavior with my patch? It's very low chance that my patch changes
> this behavior.

I have tested both with and without your patch. As expected, the patch has no 
impact on the AuthzSVNAnonymous issue.

There seems to be an issue when "AuthzSVNAnonymous Off" is combined with 
"Satisfy Any"; opens up the fort completely. Neither authn nor authz is 
required.

I think the problem is with access_checker, perhaps this part (has changed a 
few times during the years):
  if (!conf->anonymous
  || (! (conf->access_file || conf->repo_relative_access_file)))
return DECLINED;

I am not quite sure how a DECLINE manages to bypass "Require valid-user" 
though. I understand how an OK would though.


>> - What is going on with AuthzSVNAnonymous Off? I will do more analysis of the
>> code (focusing on access_checker in mod_authz_svn.c) but it would be great if
>> someone could elaborate a bit on the intent.
>> 
> It would be nice if you confirm that my patch does not change
> AuthzSVNAnonymous Off behavior in this case I'll commit my patch and
> we may focus on this issue.

Confirmed as far as my testing goes (did not test short_circuit). I suggest 
committing the patch with GET subrequest and potentially change all to HEAD in 
a separate commit if there is consensus. 

Thanks again,
Thomas Å.

Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build

[Stefan Fuhrmann]

On Sun, Nov 11, 2012 at 7:14 PM, Branko Čibej  wrote:

> On 11.11.2012 17:14, Stefan Fuhrmann wrote:
> > On Sun, Nov 11, 2012 at 4:48 PM, Daniel Shahaf  >wrote:
> >
> >> I don't know about conditionals in .vcproj files, but I assume it would
> >> at least be possible to drop an #error directive guarded by an #if
> >> directive on the compiler version.
> >>
> >
> http://code.google.com/p/notepad2-mod/issues/attachmentText?id=59&aid=59000&name=compiler.patch&token=swu5D1m0KOU9RZ7KwjULuOxXKEI%3A1333263575004
> >
> > (scroll to the bottom)
> >
> > We could simply forbid release builds with VS2010 RTM
> > by #error out in e.g. svn_types.h
>
> svn_private_config.h, please. Weird checks like that go there, and it's
> already platform-specific enough that we won't pollute the Unix version..
>

Of course. I simply hadn't found that header because it's not in
svn/include.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build

[Branko Čibej]

On 11.11.2012 17:14, Stefan Fuhrmann wrote:
> On Sun, Nov 11, 2012 at 4:48 PM, Daniel Shahaf wrote:
>
>> I don't know about conditionals in .vcproj files, but I assume it would
>> at least be possible to drop an #error directive guarded by an #if
>> directive on the compiler version.
>>
> http://code.google.com/p/notepad2-mod/issues/attachmentText?id=59&aid=59000&name=compiler.patch&token=swu5D1m0KOU9RZ7KwjULuOxXKEI%3A1333263575004
>
> (scroll to the bottom)
>
> We could simply forbid release builds with VS2010 RTM
> by #error out in e.g. svn_types.h

svn_private_config.h, please. Weird checks like that go there, and it's
already platform-specific enough that we won't pollute the Unix version..


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: Content-Length in HEAD responses

[Ivan Zhakov]

On Sun, Nov 11, 2012 at 2:28 AM, Justin Erenkrantz
 wrote:
> On Sat, Nov 10, 2012 at 3:25 PM, Thomas Åkesson  wrote:
>>
>> I suppose this means that it would be a significant optimization to
>> perform HEAD rather than GET when discovering ACLs for every subdirectory in
>> a directory listing?
>
>
> Probably - doing the HEAD request will run the full authn and authz checks,
> but it won't produce the bodies - you'll also save not having to send the
> responses on the wire - but you won't know what the directory listing is
> unless you do a GET in the first place.  So, it might help at the leaf nodes
> in the tree.  (But how would you know it's a leaf!  Fun.)
>
I've checked in debugger and it seems creating sub request performs
auth/authz without
until call to ap_subreq_run().

-- 
Ivan Zhakov

Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build

[Stefan Fuhrmann]

On Sun, Nov 11, 2012 at 4:48 PM, Daniel Shahaf wrote:

> Johan Corveleyn wrote on Sun, Nov 11, 2012 at 09:46:00 +0100:
> > On Sat, Nov 10, 2012 at 11:45 PM, Daniel Shahaf 
> wrote:
> > > Johan Corveleyn wrote on Sat, Nov 10, 2012 at 15:35:21 +0100:
> > >> On Fri, Nov 9, 2012 at 3:14 AM, Johan Corveleyn 
> wrote:
> > >>
> > >> [...]
> > >>
> > >> > Now, I have pinpointed the exact revision where the problems start
> for
> > >> > me. It's r1338286, where Bert enabled whole program optimizations
> for
> > >> > release builds, in the vcnet_vcxproj.ezt file.
> > >> >
> > >> > Maybe I'm running into some compiler bug (that has since been fixed
> in
> > >> > SP1), related to whole program optimization. I'll try installing SP1
> > >> > (but not right now, it's past 3 am now :-)) and see what happens.
> > >>
> > >> Finally got around to it, and indeed, the problem is solved when I use
> > >> VC2010 SP1. Test suite is running smoothly, and both
> > >> mergeinfo-test.exe and skel-test.exe have already succeeded.
> > >>
> > >> Now I finally have a good developer environment again, phew.
> > >>
> > >> Conclusion: don't use VC2010 without SP1.
> > >
> > > Can we make the build scripts trap that condition?  (and error out, or
> > > disable whole-program optimisations)
> >
> > Good suggestion, but I have no idea really :-). I don't know enough
> > about the build scripts and project settings, and gen-make stuff etc
> > ...
> >
>
> I don't know about conditionals in .vcproj files, but I assume it would
> at least be possible to drop an #error directive guarded by an #if
> directive on the compiler version.
>

http://code.google.com/p/notepad2-mod/issues/attachmentText?id=59&aid=59000&name=compiler.patch&token=swu5D1m0KOU9RZ7KwjULuOxXKEI%3A1333263575004

(scroll to the bottom)

We could simply forbid release builds with VS2010 RTM
by #error out in e.g. svn_types.h

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build

[Daniel Shahaf]

Johan Corveleyn wrote on Sun, Nov 11, 2012 at 09:46:00 +0100:
> On Sat, Nov 10, 2012 at 11:45 PM, Daniel Shahaf  
> wrote:
> > Johan Corveleyn wrote on Sat, Nov 10, 2012 at 15:35:21 +0100:
> >> On Fri, Nov 9, 2012 at 3:14 AM, Johan Corveleyn  wrote:
> >>
> >> [...]
> >>
> >> > Now, I have pinpointed the exact revision where the problems start for
> >> > me. It's r1338286, where Bert enabled whole program optimizations for
> >> > release builds, in the vcnet_vcxproj.ezt file.
> >> >
> >> > Maybe I'm running into some compiler bug (that has since been fixed in
> >> > SP1), related to whole program optimization. I'll try installing SP1
> >> > (but not right now, it's past 3 am now :-)) and see what happens.
> >>
> >> Finally got around to it, and indeed, the problem is solved when I use
> >> VC2010 SP1. Test suite is running smoothly, and both
> >> mergeinfo-test.exe and skel-test.exe have already succeeded.
> >>
> >> Now I finally have a good developer environment again, phew.
> >>
> >> Conclusion: don't use VC2010 without SP1.
> >
> > Can we make the build scripts trap that condition?  (and error out, or
> > disable whole-program optimisations)
> 
> Good suggestion, but I have no idea really :-). I don't know enough
> about the build scripts and project settings, and gen-make stuff etc
> ...
> 

I don't know about conditionals in .vcproj files, but I assume it would
at least be possible to drop an #error directive guarded by an #if
directive on the compiler version.


> But maybe someone else here has the expertise to pull this off?
> 
> -- 
> Johan

Re: Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125 [was: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build]

[Johan Corveleyn]

On Sun, Nov 11, 2012 at 1:59 PM, Stefan Fuhrmann
 wrote:
>
>
> On Thu, Nov 8, 2012 at 6:04 PM, Julian Foad 
> wrote:
>>
>> Stefan Fuhrmann wrote:
>>
>> > But I did run across an assertion in mergeinfo.c, :line 1174
>> >
>> >> during merge_tests.py 125:
>> >>>
>> >>>   SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
>> >
>> > The weird thing about the assertion is, that the tests
>> > will continue just fine afterwards and no error was
>> > reported. I suspect some compiler optimization issue
>> > or some missing initialization.
>>
>>
>> I see this too.  The test is marked XFAIL.
>
>
> OK, that explains why it simply carries on afterwards.
> It has been the first test that popped up the "your app
> terminated unexpectedly" window. And that is not
> nice behavior for an automated test suite.

Yeah, that reminds me that I had the same problem, already for a long
time (I don't notice it anymore). See this thread:

http://thread.gmane.org/gmane.comp.version-control.subversion.devel/125147

It's only when you run the test suite with a release build. With a
debug build, you won't get the annoying popup. But with a release
build on Windows, it's quite annoying that you can't run it
unattended...

-- 
Johan

Re: Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125 [was: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build]

[Stefan Fuhrmann]

On Thu, Nov 8, 2012 at 6:04 PM, Julian Foad wrote:

> Stefan Fuhrmann wrote:
>
> > But I did run across an assertion in mergeinfo.c, :line 1174
> >
> >> during merge_tests.py 125:
> >>>
> >>>   SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
> >
> > The weird thing about the assertion is, that the tests
> > will continue just fine afterwards and no error was
> > reported. I suspect some compiler optimization issue
> > or some missing initialization.
>
>
> I see this too.  The test is marked XFAIL.
>

OK, that explains why it simply carries on afterwards.
It has been the first test that popped up the "your app
terminated unexpectedly" window. And that is not
nice behavior for an automated test suite.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: [PATCH] Implement '--include-externals' option to 'svn list'

[Stefan Fuhrmann]

On Thu, Nov 8, 2012 at 12:34 PM, vijay  wrote:

> On Wednesday 07 November 2012 08:57 PM, Stefan Fuhrmann wrote:
>
>> On Wed, Nov 7, 2012 at 3:02 PM, vijay > > wrote:
>>
>> On Tuesday 06 November 2012 08:09 PM, Stefan Fuhrmann wrote:
>>
>> On Mon, Nov 5, 2012 at 5:24 PM, vijay > 
>> >> wrote:
>>
>>  Hi,
>>
>>  This patch implements '--include-externals' option to 'svn
>> list'
>>  [Issue #4225] [1].
>>
>>  All tests pass with 'make check' & 'make davautocheck'.
>>
>>  Attached the patch and log message.
>>
>>  Please review this patch and share your thoughts.
>>
>>  Thanks in advance for your time.
>>
>>  Thanks & Regards,
>>  Vijayaguru
>>
>>  [1]
>> 
>> http://subversion.tigris.org/_**___issues/show_bug.cgi?id=4225
>> 
>> 
>> >
>>
>>
>>  > __issues/show_bug.cgi?id=4225
>> 
>> 
>> >>
>>
>>
>> Hi Vijay,
>>
>> Not sure whether these points have already been
>> discussed in previous threads, but the following
>> two points caught my attention:
>>
>>  +typedef svn_error_t *(*svn_client_list_func2_t)(
>>  +  void *baton,
>>  +  const char *path,
>>  +  const svn_dirent_t *dirent,
>>  +  const svn_lock_t *lock,
>>  +  const char *abs_path,
>>
>> o.k.
>>
>>  +  svn_boolean_t notify_external_start,
>>  +  svn_boolean_t notify_external_end,
>>  +  const char *external_parent_url,
>>  +  const char *external_target,
>>
>> Maybe, this should be modeled to create a more "seamless"
>> appearance. Only keep the external_parent_url member.
>> If it is NULL, this entry has not been pulled in here by
>> some external. Otherwise it contains the parent URL as
>> defined by your patch.
>>
>> I don't see the see the need to expose more information.
>> Why would you need to group externals? The external_target
>> member should be given implicitly by path / dirent.
>> Am I missing something here?
>>
>>
>>
>> The external_target member will not be given by path / dirent.
>> We will get it by parsing the externals description.
>>
>> Suppose that path1 in repo1 has svn:externals set to path2 in repo2.
>>
>> When we list path1 with externals included,
>>
>> 1. First, list path1.
>> 2. Then, process all the externals defined under path1. Parse
>> through the individual external description and populate
>> external_target.
>>
>> For example,
>>
>> external description under path1:
>> external_desc = exdir  http://
>>
>> external_target = exdir
>> external_parent_url = http://
>>
>> url of external = http://
>>
>> 3. List the entries by reaching 'url of external'.
>>
>>
>> OK, I now see what you are trying to do here -
>> I had read to much into the code.
>>
>> However, in this form, the added functionality is
>> of limited use, IMHO. I understand that what you
>> list is basically which paths you would get for a
>> "svn co $url".
>>
>> While this is fine, I see two issues with it:
>>
>> * trees don't get overlayed. Example:
>>$>svn ls $URL -R
>>sub1
>>sub1/fileA
>>sub1/fileB
>>sub2
>>$>svn propget "svn:externals" $URL
>> http://somewhere/ sub1/subsub
>>$>svn ls $URL -R --include-externals
>>sub1
>>sub1/fileA
>>sub1/fileB
>>sub2
>>sub1/subsub [external].
>>
>>Desired output
>>sub1
>>sub1/fileA
>>sub1/fileB
>>sub1/subsub [external @$URL].
>>sub2
>>
>
> I was referring externals related code base in checkout/update and export
> while implementing this option.
>
> From subversion/libsvn_client/**update.c
> 
> /* We handle externals after the update is complete, so that
>
>  handling external items (and any errors therefrom) doesn't delay
>  the primary operation.  */
> 
>
> So I preferred the same for 'list' also. But there is a difference in
> externals processing between the commands checkout/update and list. The
> former processes the externals by default. The latter processes externals
> only if we specifically ask it. What should we do here?


I think if the goal is to behave the same way
that export / co do, then your approach is
correct. I can live with that.

Listing externals seems to be unu

Re: svn commit: r1311476 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c

[Stefan Fuhrmann]

On Fri, Nov 9, 2012 at 2:07 PM, Stefan Sperling  wrote:

> On Mon, Apr 09, 2012 at 09:46:34PM -, stef...@apache.org wrote:
> > Author: stefan2
> > Date: Mon Apr  9 21:46:34 2012
> > New Revision: 1311476
> >
> > URL: http://svn.apache.org/viewvc?rev=1311476&view=rev
> > Log:
> > Turn hard-coded deltification parameters into config parameters
> > for format 4 and later (they all keep compatibility with 1.6 and 1.7).
>
> I just came accross this snippet in the config:
>
> > +"### The following parameter enables deltification for properties on
> files"  NL
> > +"### and directories.  Overall, this is a minor tuning option but can
> save"  NL
> > +"### some disk space if frequently merge or if you frequently change
> node"   NL
> > +"### properties.  You should not activate this if rep-sharing has been"
>  NL
> > +"### disabled."
>  NL
> > +"### property deltification is disabled by default."
>   NL
> > +"# " CONFIG_OPTION_ENABLE_PROPS_DELTIFICATION " = true"
>  NL
>
> I don't like the sound of "You should not active this if..."
>

Changed the wording in r1407959.


> This sounds as if we're relying on users to keep their configuration
> files consistent to get proper behaviour, which I hope isn't the case!
>
> What happens if this option is activated anyway? Will the user be
> left with a corrupt repository, or will the option have no effect,
> or something else?
>

It will still use DELTA representations instead of PLAIN
for properties. There is no functional hazard here, this is
about efficiency only.

The point is that DELTA reps come with a ~10 byte overhead
for the initial rep in the delta chain. With rep sharing enabled,
only a few reps will contain file properties (all shared between
many files), so there will be little total size overhead.

OTOH, properties on folders are often larger (compression
will kick in above 512 bytes) and change from time to time
- mostly due to mergeinfo. Here, deltification will save high
percentages of the plain property rep size.

But as the comment says, the total savings are usually
small which means that even small, yet frequent, overheads
may result in a net increase of repository size.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build

[Johan Corveleyn]

On Sat, Nov 10, 2012 at 11:45 PM, Daniel Shahaf  wrote:
> Johan Corveleyn wrote on Sat, Nov 10, 2012 at 15:35:21 +0100:
>> On Fri, Nov 9, 2012 at 3:14 AM, Johan Corveleyn  wrote:
>>
>> [...]
>>
>> > Now, I have pinpointed the exact revision where the problems start for
>> > me. It's r1338286, where Bert enabled whole program optimizations for
>> > release builds, in the vcnet_vcxproj.ezt file.
>> >
>> > Maybe I'm running into some compiler bug (that has since been fixed in
>> > SP1), related to whole program optimization. I'll try installing SP1
>> > (but not right now, it's past 3 am now :-)) and see what happens.
>>
>> Finally got around to it, and indeed, the problem is solved when I use
>> VC2010 SP1. Test suite is running smoothly, and both
>> mergeinfo-test.exe and skel-test.exe have already succeeded.
>>
>> Now I finally have a good developer environment again, phew.
>>
>> Conclusion: don't use VC2010 without SP1.
>
> Can we make the build scripts trap that condition?  (and error out, or
> disable whole-program optimisations)

Good suggestion, but I have no idea really :-). I don't know enough
about the build scripts and project settings, and gen-make stuff etc
...

But maybe someone else here has the expertise to pull this off?

-- 
Johan