Point taken.
However, did you seem my email about the workflow that that limitation is
going to cause the web application developer? Since things have to be
tested on the web server, and since the GUI can't manage a check-out to the
web server, we would have to download and upload MANY MORE BYTES and make
much more use of the "spare rescource" you refer to.
Anyway, I'm not trying to pick a fight. I'm just disappointed, that's all.
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Monday, January 24, 2005 12:17 AM
To: Brian W. Fitzpatrick
Cc: JC Hearn; 'Branko Čibej' ; 'Peter McNab'; users@subversion.tigris.org
Subject: Re: Subversion GUI client?
On Jan 23, 2005, at 10:59 PM, Brian W. Fitzpatrick wrote:
>
> 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.
>
Subversion is modeled after CVS, which is designed for widespread
collaboration over a WAN. We didn't start out making weird
assumptions: we started out with CVS's model, which is perhaps the
most successful version control system ever, at least in the open
source world.
CVS and Subversion assume that network connectivity is a spare
resource, that users will be offline now and then, or have little
bandwidth. So the working copies are things that are created
locally... and then only occasionally sync by uploading/downloading
changes from the server's repository. Users work in isolation as much
as possible, making use of their own disk resource, rather than the
server's.
It sounds like you're talking about a completely different beast,
something like a file server that everyone creates workspaces on. That
model isn't particuarly interesting to us, because file servers already
exist. It's not a wheel worth reinventing. It's also not scalable:
consider a huge project like GNOME. At the moment, anybody is free to
"checkout" the source to a private working copy to toy with it.
Imagine if those thousands of anonymous users started building
workspaces on the server instead!
Subversion is not a file server. It's also not a remote web-site
management system.
---------------------------------------------------------------------
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:30:03 2005