Re: Space wasting

so the other $4 question is: instead of trying to anticipate every
single possible way that the contents of the .svn directory can be
changed, and write code that tests for it, wouldn't it be easier try to
prevent it from being changed in the first place? thereby obviating the
need for checks?

it sounds like basically every time someone thinks of a way the
directory can be changed, code is added to test for it. now you have
code that checks for structure modifications, checksums, and whatever
else. these checks add complexity, detracts from performance, and makes
code maintenance much more difficult. this is especially true if you
have to later on change the contents of that directory/how it works,
because now you have to come up with another suite of tests.

i would actually feel much better if you just assumed the contents were
correct and did no checking. at least then the (valid) rationale would
be code simplicity/maintenance/performance. trying to guess all the ways
the contents can change is specific only to that structure (upgrade
resistant) and probably not the best approach.

-alvin

subversion@millenix.mailshell.com wrote:
> Alvin Thompson wrote:
>
>> [snip]
>> also, you're assuming that the programmer made a conscious effort to
>> change the contents. much more likely it would be the result of a
>> 'bad' script or an unintended side effect of a command. worse, it may
>> go unnoticed since most do not inspect the contents of that directory.
>> the $4 question is: what will happen to the users wc/repository when
>> the contents of that directory are modified in a non-deterministic way?
>
>
> Simple: svn sees that the working-copy management area has been
> modified, and errors out. A patch has just recently been added to
> compare the checksums of the text-base files to the recorded checksums
> to make this even safer.
>
>> are you saying that you have never, ever accidentally modified/deleted
>> a file you didn't intend to? i have, and i'd be willing to bet that
>> most have. it happens rarely for 'smart' people, but once every blue
>> moon it still happens.
>
>
> Of course it happens, and svn catches it before anything beyond your own
> changes get destroyed by your own script-gone-mad.
>
> Philip Miller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

-- 
Alvin Thompson
Navy: 34
Army: 6
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org