I don't follow you.
Are you saying that "working copy on local file system" is a fundamental
design concept of subversion? Why?
It seems to me that the working copy just needs to be in a different spot.
Why insist that it be local? Why not check files out from a repository
server to a development server, for example?
It doesn't seem to me that the "local copy" concept would support web
developers that well, unless I am completely missing something here.
-----Original Message-----
From: Brian W. Fitzpatrick [mailto:fitz@collab.net]
Sent: Sunday, January 23, 2005 11:59 PM
To: JC Hearn
Cc: 'Branko Čibej' ; 'Peter McNab'; users@subversion.tigris.org
Subject: Re: Subversion GUI client?
On Jan 23, 2005, at 9:08 PM, JC Hearn wrote:
> You are right to suggest that this is not a shortcoming of Subversion.
>
> However, the developer community which has grown up around Subversion
> seems
> to have made an incorrect assumption (unless I am completely
> misreading the
> various documentations, which I will allow as a very real possibility.)
>
> That incorrect assumption seems to be that it is OK to access the
> repository
> via HTTP, SSH or FTP, but the working copy MUST be accessed via the
> local
> file system. Why not allow the same access to the working copy? Why
> force
> the user to open additional security issues (such as those associated
> with
> SAMBA)? Or even better, why not have an API to allow the user to move
> files
> from one place to another on the web server?
That "incorrect assumption" is one of the *fundamental* design concepts
that Subversion is built around. Subversion was never intended to be
used in the manner in which you describe.
That's not to say that it can't be done, but doing what you want is
like trying to cut a steak with a spaceship.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 24 06:14:04 2005