On 31/01/2013 6:06 PM, Bob Archer 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). 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.
>>
>> The inital update between the file server and the software update server would
>> require rsyncing the whole 60 GB of software to a "working directory", after
>> which, to make subversion see this as a "working directory", I would have to
>> commit the entire directory, then check it back out. This process seems like a
>> bit of a waste, but it's a one time process, and I don't really see any way around
>> it. In the future, I would like to be able to rsync changes between the file
>> server and the working directory on the software distribution server, which
>> would including using --delete to ensure that software deleted from the file
>> server is also deleted from the subversion working idrectory, and including the
>> excluding of the .svn directory from the working copy.
>> 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. I believe you need to use "svn delete" for this?
>>
>> Any ideas that anyone might be able to offer?
>>
>> I'm not on the list, so please ensure that you CC: me in any response.
>>
>> Thanks for your help!
>>
>
> What you need to do could work. I assume this "software" in order to run can build built or whatever during your nightly update on each client?
>
> You keep saying "rsyncing" ... you wouldn't use that. You wouldn't use that of course, you would use the svn client binary.
Actually, maybe I wasn't clear..
The software includes various packages like say, Matlab, or Maple, or
whatever else, already installed... imagine a directory on the
fileserver.. say, /local/software which includes "bin", "lib", etc...
I'm not "installing" the software. it's already been installed.. I'm
just syncing a directory between machines..
As for rsyncing.. I would rsync the software from the "file server" to
the "software distribution" server, and then use svn from there to check
in all the changes.
> For you initial load... if the software is on the server where you will house your repository you can just import the data into the repository from that file... there is no need to send the data twice. In other words, you can have both a working copy and a repository on your central server.
Yes. Initially I would do an import, but the problem is... the next
day, the software gets updated on the "real" file server... say, new
version of Matlab or something... in the evening, I want the process to
run that would rsync the data (with all the changes) from the file
server to the software distribution server, do something to commit the
changes, then the 100 clients would eventually each "svn update".
However, to be able to commit the changes, I need to have a working copy
on the software distribution server....
>> 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"
> "svn update" brings any changes in the repository to your working copy. "svn commit" does the opposite... it puts any changes in a working directory into the repository.
See, this is where I'm confused... I created a few directories including
"bin" and "pkg" for a test. All committed fine... erased them from the
working copy, did a commit then a status and I see:
! bin
! pkg
but when I go into a different directory and check out the current state..
A pkg
A bin
Checked out revision 2.
they're still there...
> Hth...
>
> That said, if this is actual software, wouldn't using one of the many package management tools available in Linux be a better fit?
The thing is, I'm moving around already installed software, and there's
nothing that great, as far as I can see, for doing that. The twitter
guys are using something they wrote called "murder" which uses torrent
to do this kind of thing... excellent idea, but it uses Ruby and
several other tools ... and I don't want to get into that at the moment...
Jason.
Received on 2013-02-01 03:05:35 CET