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

Re: "Hotsync"

From: Thomas Hruska <thruska_at_cubiclesoft.com>
Date: 2006-07-17 04:22:41 CEST

Steve Williams wrote:
> Thomas Hruska wrote:
>> Jody Shumaker wrote:
>>>> That doesn't change the fact that I still want the feature. I've
>>>> figured out how to write a utility that does this by reading the
>>>> .svn/entries file in each WC directory, extract 'name', 'kind', and
>>>> 'checksum' (looks like MD5) from each entry, and then replicate just
>>>> those files at the destination.
>>>> Combining this into a Beyond Compare plugin should suffice as a
>>>> reasonable solution. Maybe. I'd modify the source to TSVN, but the
>>>> setup requirements demand huge changes to my compile-time and runtime
>>>> environments that I'm going to risk over such a minor change. It is
>>>> one
>>>> dialog, a little code to map dialog interaction to internal variables,
>>>> and calling the code that retrieves filenames from a WC and then simply
>>>> copies each file to the destination (plus 'delete' files marked for
>>>> deletion in the WC). Essentially a one hour task for someone who knows
>>>> the code base.
>>>> --
>>>> Thomas Hruska
>>>> CubicleSoft President
>>>> Ph: 517-803-4197
>>> You could probably also do this via patches. I don't have much
>>> experience with using them, but the basic idea would be to create a
>>> patch of your modifications on one pc, transfer it to the other pc,
>>> revert th eother pc to a clean working copy, then apply the patch. It
>>> will only be applying diffs and thus be a smaller set, and it will
>>> only work on files svn knows about.
>>> - Jody
>> An interesting suggestion and the only one that I've seen that makes
>> any sense. Unfortunately, I gave it a try and TSVN choked on a
>> directory containing over 15,000 files - of which only a handful are
>> actually in the WC. Well, 'choked' may be the wrong word. "Took a
>> very long time to return control to the user" is probably more
>> accurate. I've also tried using 'svn diff' but that has problems with
>> the binary files in my WCs.
> Windows Explorer has slowdown issues with that number of files in a
> directory anyway,

I know that but it is usually only a few seconds. 10-15 seconds is
fine. 5 minutes isn't. TSVN takes 5 minutes on the same data.

  and then you add TSVN on top of that, which has to do
> a check on every file to see if it is in source control or not. Our

TSVN is issuing the commands to the OS from an interactive dialog
(Create Patch...). That is, Explorer is not involved (except maybe the
PIDLs to retrieve the icons for the file types - but that should be
cached information in a partial hash). It should also be predicting
what the next file will be in a WC that matches the OS directory listing
API calls to minimize effort to a O(1) operation and O(log N) at worst.
  At worst, this process should only take slightly longer than Explorer
but I expect TSVN to take 50% less time than Explorer in scenarios where
it has control (e.g. interactive dialogs) because I know it is possible.

My guess is that it is a combination of identical PIDL retrieval and
TSVN not predicting OS directory listings that is the source of the

Thomas Hruska
CubicleSoft President
Ph: 517-803-4197
Safe C++ Design Principles (First Edition)
Learn how to write memory leak-free, secure,
portable, and user-friendly software.
Learn more and view a sample chapter:
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jul 17 04:22:53 2006

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