On Thu, Jan 31, 2013 at 8:14 PM, Jason Keltz <jas_at_cse.yorku.ca> wrote:
>>
>> I'd think it is exactly the problem that rsync is intended to handle.
>
> rsync is great when you want to sync the contents from one machine to
> another machine in one direction.. (unison if you need dual direction
> sync...) .... I thought about using rsync to solve this problem... two ways
> I can think of..
>
> 1) All the machines run rsync against the server.. kills the server, but
> let's say they do it all at different times.. the server is hefty.. hey, it
> would work, but for every single rsync, the server needs to look at its
> entire file tree to see which files have changed.... 100 syncs = 100 times
> processing the same thing over and over again... If only rsync would let me
> save that state to a file so that it doesn't need to reload it every time it
> runs, then I know which solution I'd be using... other problem is, it would
> take a long time..
Is this on linux? If the host has a reasonable amount of RAM the
directory info will mostly be cached between accesses. Have you timed
it before deciding it is a problem? I suspect it won't be unless
there are millions of small files in that tree or a very fast rate of
change.
> 2) log/tree approach --- server updates one client, then the server and the
> one client each update another client, then each of those 3 update
> another... much faster, but again, you have to read the server state each
> and every time... and then I have to deal with the fact that various random
> machines are off ...
If you can't complete from one distribution server - or if the
geographic location makes sense, fan it out to a few redistribution
instances. Not sure what you mean about reading server state -
directory reads aren't all that expensive.
>> Subversion would give you the option of intentionally maintaining your
>> targets at different revision levels, but at a cost of needing a
>> 'working copy' format where you have an unneeded 'pristine' duplicate
>> copy of everything.
>
> The truth is, I wouldn't intentionally have the machines at different
> software levels... (well, that could be useful for testing, but that's
> another story).... but a machine could be off during the update and would
> be able to "catch up" no longer how long it was off...
Rsync would always catch up. If the exact refresh timing isn't
critical you could just run from cron on the clients with some skew to
avoid overloading the distribution server.
>>> I believe you need to use "svn delete"
>>> for this?
>>
>> That is for when you are making the changes you intend to commit.
>>
>
> I'll have to try that again .. didn't seem to be working the way I expected
> it to...
You have to 'svn delete' in the working copy, then commit the change,
then an update will replicate the action in another working copy.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-02-01 07:05:36 CET