BTW, very large in this case means ~17 GB :) -- -Antti-
2008/1/25, Antti Luoma <[EMAIL PROTECTED]>: > > Hi, > > I did take a look from sources and noticed the basic java File API, I > think there might be some optimization (like getting rid of unnecessary > vector creation). Also caching src folder contents (is maybe storing > contenst to outputstream directly and reading from there) might improve it? > This of course is if you sync SAME directories.. Or maybe somebody has an > even better idea? > > I'm stuck with windows platform (due to sdk that I'm using).. But i'll > think I give rsync a try (even though used linux for years this is something > that I haven't worked with before). It might even work better on my case > (client / server model..). Only side effect it that i'll need another > prorgram and more setup to make this system rock (not so easy to transfer to > another machine, that would have been the best part with using build in ant > tasks). > > But thanks! > > > -- > -Antti- > > 2008/1/24, Dominique Devienne <[EMAIL PROTECTED]>: > > > > On Jan 24, 2008 3:53 AM, Antti Luoma <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I am using ant 1.7.0 <sync> task to sync 2 very large directories. It > > > currently takes too much time to do this (to be usable). > > > > Sorry Antti, but there's no free lunch. Either you want to sync, in > > which case you need to scan both the source and the destination > > folders, or you don't. The whole point of sync is that things can > > change in either folders, so you must scan them to know what. > > > > <sync> uses a simple minded algo, using existing Java File APIs, which > > aren't that fast, especially with remote file systems. I don't see how > > to speed it up without compromising the goal of syncing things. > > > > rsync OTOH is a much smarter approach, but relies on a client-server > > approach where both the source and destination must be rsync-enabled > > to be really fast (AFAIK), and not very win32-friendly (I could not > > make it work with UNC paths for examples). > > > > 15 hours is a long time. That must be one mighty big folder... --DD > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > >
