subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Keltz <...@cse.yorku.ca>
Subject Re: software distribution with subversion
Date Fri, 01 Feb 2013 02:14:04 GMT
On 31/01/2013 6:40 PM, Les Mikesell wrote:
> On Thu, Jan 31, 2013 at 4:10 PM, Jason Keltz <jas@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


Mime
View raw message