[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[OT:really:OT] Re: [OT] Re: [BUG] The client can't use a different directory than .svn

From: Ryan Hunt <rhunt_at_hp.com>
Date: 2003-12-12 18:52:47 CET

On Dec 12, 2003, at 10:32 AM, Mike Mason wrote:
> Ryan Hunt wrote:
>> The disk images are read only for all but the maintainer group of not
>> more than 5-10 people. The rest just read the files.
> (We're probably boring people by now, sorry folks!)
> So a user has a disk image, they're using it, running a VM, have it
> mounted, whatever. A maintainer comes along and wants to change that
> image -- how do they do that? Do they do it under the feet of the
> person who has it mounted, or must they wait for a dismount?

preferably a maintenance time would be preferred, but the owner of the
file can theoretically rip the image out from under the user.

> Could you have a mechanism where each user has a selection of the
> images checked out (their own WC with a few images in it) on a local
> disk, and a script that updates their images when a new version is
> available? Something like a nightly "svn update" to get the latest
> changes.

This would be nice in many ways, but disk space can be a problem on the
client. Also the network traffic can get to be too much of a problem
if the client base is sizable

> How fast should a user get the changes made by a maintainer?
> Instantly? Within an hour? Overnight?


> Could you have a read-only WC for all of your users with automated
> "svn update" running over the full 5TB, and individual (smaller)
> working copies for each of the maintainers who actually need to change
> the files?

To complicated. We are trying to move to an automated system.

Are you working with VMware at all? VirtualPC?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 12 18:51:16 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.