[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] [updated] [Issue 870] import should set svn:executable automatically

From: Brian Denny <brian_at_briandenny.net>
Date: 2002-09-30 01:54:00 CEST

On Mon, 30 Sep 2002, [UTF-8] Branko Čibej wrote:

> Doesn't that simply mean that the greek state should encapsulate
> executableness somehow? Changing these calls will just make the tests
> slower.

probably you already understand this better than i do, but let
me be more explicit about what is going on, just to make sure
we have the same understanding of the issue.

'execute_and_verify_update' has a parameter called 'check_props'.
when this value of this parameter is 1, it does a proplist on
every file of the actual disk, and compares those properties
on the properties found in the expected_disk. therefore the right
props must be set on expected_disk. the only way i know how to do this
is by calling
  tweak('kappa', props={'svn:executable', ''})

if, OTOH, the value of 'check_props' is 0 (which is the more common
case), then the prop must NOT be set on the expected_disk.

furthermore, the prop must never be set on an expected_status
(which is also created by copying the greek_state).

so, the way i see it, if the original greek_state somehow
encapsulated executableness, we would still need a way of making
sure that executableness got taken into account some of the
time, and not others.

originally i just called 'tweak...' inline, in those places where
it was necessary. then i decided to factor out a helper function.
(partly i'm just the sort of person who never likes to have the same
two consecutive lines of code duplicated, but the refactoring also
made sense by analogy to 'get_virginal_state', which is used every
time an expected_state is needed.)

i'm definitely not tied to this way of doing things, but i haven't
thought of a good alternative. if there is something that i am
overlooking or misunderstanding about the test code, please let me
know. otherwise, do you have any suggestions?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 30 01:58:38 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.