On 31/01/2013 6:40 PM, Les Mikesell wrote:
> On Thu, Jan 31, 2013 at 4:10 PM, Jason Keltz <jas_at_cse.yorku.ca> wrote:
>> I am faced with a problem where I need to distribute a directory containing
>> about 60 GB worth of software on a Linux file server to about 100 systems.
>> The software must be localized on those systems and not shared out over NFS.
>> On a regular basis, software may be added or removed from the directory, and
>> all the clients should update accordingly in the evening. During the update
>> period, some client systems may be off.
>>
>> I think that Subversion would be a reasonable way to solve this problem
>> which isn't quite the type of problem that rsync is intended to handle
>> (because of the number of machines).
> 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..
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 ...
It's a really interesting problem..
>> However, for a variety of reasons, I
>> don't want to run subversion on the actual file server. Instead, nightly,
>> I'd like to rsync changes in the contents of the software directory on the
>> file server to a software distribution server which would run its own
>> svnserve. The clients would then connect up to the server nightly, and
>> update themselves accordingly. Because of the versioning, if a client
>> misses an update, it would be updated the next time around, even if its been
>> off for a while.
> 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...
>> However, after the rsync happens, I now need to run a
>> command that would update the repository with the state of the working
>> directory. However, it's not exactly clear how this would work? Running an
>> "svn update" isn't going to delete directories from the repository that were
>> deleted from the working directory.
> Sure it will - it will make it match the state of whatever version you
> are updating to.
>
>> 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...
Jason.
--
Jason Keltz
Manager of Development
Department of Computer Science and Engineering
York University, Toronto, Canada
Tel: 416-736-2100 x. 33570
Fax: 416-736-5872
Received on 2013-02-01 03:14:34 CET