Stefan Küng wrote:
> On 11/30/05, Joseph Galbraith <galb@vandyke.com> wrote:
>
>> Do I understand correctly that when the cache gets a file
>> change notification, it re-crawls that section of the file
>> hierarchy? Or does it only re-get status on files that
>> are reported as having been changed?
>
> It recrawls the folder where the modified file is in. That's because
> svn_client_status() always gets the status of all files in a folder,
> no matter if you specify the folder of a file within in the parameters
> (it just will filter out the status info of all other files if you
> don't specify the folder).
>
>> If it re-crawls for a change notification, what if we used
>> a simple named mutex to serialize activities?
>>
>> So the cache would grab the mutex before it starts a crawl,
>> and TSVN proper would grab the mutex before it started an
>> update/checkout or other command that would trigger a-lot
>> of changes.
>
> I thought of that too. But it's risky and not quite as easy to
> implement as you might think right now:
> - the cache is shared between *all* users on the computer the cache runs
> - you can have multiple svn operations running at the same time and
> working copy (i.e. several instances of TortoiseProc). So a mutex
> wouldn't be enough, you'd have to *count*, or one TortoiseProc could
> release a mutex which another instance created. (semaphores are
> needed)
No this seems to be a killer ... I can't think of any simple
way to get around this one.
> - what happens if TortoiseProc crashes without releasing the
> semaphore? The cache would be prevented from crawling forever?
Well, for mutexs at least, this one at least has a simple answer.
Since the mutex / semaphore are kernel objects, the kernel
automatically releases them when a process owning them goes
away. This results in the WaitForXxxObject() returning
WAIT_ABONDONED or something like that.
> - a simple semaphore/mutex/whatever wouldn't be enough: stopping the
> cache globally isn't a good idea, we should only stop it for certain
> paths. So we'd have to assing a path somehow to the "lock".
Yes... that is what I meant by the locking granularity being
pretty big.
>> It wouldn't be perfect as it wouldn't handle the command line
>> client and the locking granularity is pretty big... but it
>> would pretty well eliminate the cache and TSVN competing
>> with each other.
>
> Oh yeah, other svn clients exist too ;)
>
>> Another possibility (if the svn apis let you) would be to have
>> check to see if the working copy is locked before starting a
>> crawl.
>
> In such a case, the crawler would simply return immediately because
> svn_client_status() would return with an error.
Ah well, another ill thought out idea shot down in flames :-)
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Nov 30 16:28:42 2005