On Saturday, September 28, 2002, at 08:47 PM, Justin Erenkrantz wrote:
> On Sat, Sep 28, 2002 at 08:31:58PM -0400, Garrett Rooney wrote:
>> but he's not asking for reserved checkouts, he's just asking for some
>> model where the client already knows what files you are editing, so it
>> doesn't have to stat everything to check when you want to diff or
>> commit or whatever.
>
> And, that can't work, either. You have to prevent anyone from
> circumventing the process. And, the only way to do is to take
> perforce's model of becoming the file system or enforce components
> of the development environment. (Some work is being done here on
> adding development tools for precisely this level of awareness.)
(note, i don't particularly care one way or another about this feature,
i hate having to do 'p4 edit' when i use perforce at work, and it seems
like larger projects should be able to structure their repository and
build structure such that the developers can check out smaller parts
rather than the whole thing.)
that said, i don't think we have to make it 'perfect'. if the client
actively works around the version control system, then hell with them.
what's the worst that can happen? they start editing a file without
telling svn (if we're making all files read only, they chmod it or
something), then, later, they do an 'svn commit', the file doesn't get
committed because svn doesn't think it's change. their changes break
the build or cause bugs or whatever, and they get yelled at by the
other people in the project. good, they got what they deserved.
>> this information /might/ be kept server side (like in perforce), but
>> that doesn't mean that the fact that i'm editing a file means nobody
>> else can. knowledge of what i'm working on != locks.
>
> Any model based on pro-active usage of 'svn edit' is going to
> be prone to failure conditions where modified files will not be
> detected. Therefore, the only way to correctly identify if a file
> is changed is to do a diff/crc/etc of the on-disk file with what we
> already know about the file. Since SVN isn't the file system, we
> must admit that we will have no knowledge of when a file changed.
>
> This failure mode is more troublesome than any speed improvements.
> Entry caching, of course, makes SVN way faster than it has been
> before. So, I don't buy that large project WCs can't scale now.
i agree that we should be fast enough to compete without this, but if
people absolutely want this feature, i don't think 'the user can work
around it' is a good enough reason to say no. the user can already
mess with the version control tool in about 17 different ways by
editing the files in the .svn dir, we just try to make that as hard as
possible by making them read-only, etc. i don't see how this is
different.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 29 02:59:57 2002