On Dec 3, 2007, at 9:52 AM, Miller, Eric wrote:
>>> I would really like to be able to implement a light-weight working
> copy
>>> using symbolic links that point to a common read-only area,
> replacing
>>> the links with editable data when locks/edit permissions are
> granted.
>>>
>>> Does anyone have any ideas if something like this is feasible in
>>> subversion?
>>
>> A common shared area is interesting, but probably hard to implement.
>> Think about permissions, who actually updates the common area, etc.
>
> I guess I was thinking that some sort of daemon or post-commit hook
> would take care of updating the common area. The real tricky part is
> handling mixed revisions and branches.
>
>> I believe someone thought about keeping the pristine files in a
> compressed
>> format. This might reduce the space at least a little, with the
>> possibility of not too many complex working copy code changes.
>
> I guess this would help incrementally depending on the type of
> data, but
> it doesn't help with duplication of the actual data.
>
> Guess I'm looking at something that is pretty far removed from
> svn's use
> model (again). It was a shot in the dark - thanks for the response!
>
the intent of the SVN local workspace was for it to be physically
local, i.e. on the
same disk. this reduces network activity and helps SVN status
performance (SVN
status is *really* slow over most LAN's i've seen, unmanageably slow
over WAN).
If your users "local" workspaces are actually on some central file-
server someplace
you're really using SVN the way it was designed.. Net-apps are
convenient
for IT support but are generally the wrong solution for this kind of
use model.
I usually hear IT people complain that local disks are difficult to
manage when it
comes to backups, in this case however users should be committing
regularly and
local backups are not such a big issue..
so this extra disk space is a good thing in my opinion if the
environment is
architected properly, if it isn't then you're not really getting full
value from SVN
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 3 19:15:32 2007