> Hi,
>
>> The problem is subversion doesn't have control over when a file is
>> modified and therefore can't enforce the copy-on-write. Any user with
>> any application (text editor, build tool, IDE, script) is going to come
>> along and simply modify the files because they exist in a normal
>> filesystem. At that point, it is too late to copy the original to
>> create the text-base.
>> [...]
>> The only other way to deal with this would be to enforce controlled
>> access to the wc. Since all tools (IDE, text editors, etc.) are used to
>> dealing with a regular filesystem, you'd have to build a virtual
>> filesystem wc that did copy-on-write. But that's a whole different
>> project.
>
> Or you could have an option to have Subversion operate like Perforce,
> where one has to
> p4 open
> p4 edit
> prior to editing a file. Files that haven't been edited/opened shouldn't
> be modified by a text editor, build tool, IDE, script. This is enforced
> by using the filesystem's permissions. I know a simple chmod works
> around this scheme on POSIX systems, but it does work for Perforce users
> and I personnaly like to be warned that "somebody else is already
> editing the file" when editing/opening it.
>
We use perforce pretty heavily here and this is one of it's biggest
disadvantages. Many people not used to dealing with version control
that don't use p4 edit get bitten when they make this file locally
writable and tend to regard version control from then on as a hindrance
instead of a tool.
Although it is not perfect, another way to save space would be to use
file checksums to determine if the full text is needed locally before
copying the full text from the server. This seems like it could be a
relatively low-impact modification to the current WC model that could
reduce the amount of wasted space. For people who want to work offline,
this wouldn't be an advantage, but for those who work solely on a LAN,
this could be a huge win and it seems like it would be possible to make
this a WC toggleable option.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 16 19:18:45 2004