Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
alexey-panchenko at hotmail.ru wrote: > be done in two steps. The first step will find the subset of the locks > for the specified path. The second step will check each of those > locks. Probably the nested container should not be a map, and a vector > or a linked list will be enough. A multimap will also handle that (although a map + vector will be more compatible I agree, as not all STL implementations have multimap). The problem then becomes keeping it up to date without introducing overhead in the rest of the code. Ideally there'd be such a thing as a map that automatically mapped bidirectionally, then you'd only need one. Might even be worth writing such a beast just for this. > Am I missed something ? Yes. The Case option is never sent by newer versions... it's just for backward compatibility. I could remove it without much issue as people generally don't mix different versions of cvsnt with different lockservers. > lockserver is called at least twice (lock & unlock) for each file > during update, so it also uses CPU. Unlock is pretty trivial though. lockserver itself isn't on the critical path normally (not including the case where you get leaking locks of course). What is an issue is the interprocess communication overhead... threading in the new versions helps there. Tony