On Thu, Apr 10, 2008 at 8:22 AM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Thu, Apr 10, 2008 at 10:01 AM, Harvey, Edward
> <Edward.Harvey_at_patni.com> wrote:
> > > libsvn_wc rewrite which
> > > (1) centralizes metadata in one place and
> > > (2) allows users the option of 'svn edit' to tell svn what you're
> >
> > > changing, so that 'svn status/update/commit' no longer need
> > > to traverse the tree.
> >
> > With the wc rewrite, are you talking about somehow preventing extraneous processes, such as "vi somefile" from accessing files in a WC "behind the back" of the svn client?
>
> Just like perforce, the whole working copy would have read-only
> permissions set by default; 'svn edit' would make a file read-write.
>
> Yes, this system is imperfect, but it works pretty well in practice in
> conjunction with user education. We already have this behavior when
> the 'svn:needs-lock' property is attached to the file... we'd just be
> generalizing the behavior to cover the whole working copy. (Some
> naughty tools ignore read-only permissions, but typcially not text
> editors.)
By the way, a nice thing about this model that epg pointed out
recently is that this mode meshes well with optional text-base-free
operation. You can get away without storing a separate text-base for
the read-only files; 'svn edit' would add a copy of the text-base to
the metadata area before making the file writable.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-10 18:19:57 CEST