> > 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
I don't think you understand the suggestion. All state that's kept is
local. If you want to not use this model, you're welcome not to -- the
draw-back for you will be that subversion has to crawl through your
entire source tree to figure out what needs to be done when you go to
check in -- i e, the current behavior.
Note that the suggestion on the table is that the user, on initial
check-out (or subsequent special command) decides which of these modes
he wants to work in -- again, this is all about using client-side state
to accelerate time-consuming operations.
> 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.)
You must be confusing Perforce with ClearCase. Perforce does not enforce
any components (other than itself, naturally). However, perforce keeps
server-side state, which is good for what they do, but means that you
can't mv or cp or rm your client-side tree without telling the server.
The suggestion I'm making does not suffer from these problems.
> 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.
All really large projects in the world use the "open to edit" model,
AFAIK. The CVS model just doesn't scale large enough. If you think
you can't help yourself but to override that warning your editor will
give you when trying to overwrite a read-only file, then you are
perfectly welcome to not turn on the client-side edit list optimization,
and instead wait the extra 10 minutes on "status", "diff" or "checkin".
> 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.
If that's the only model you want to work with, then you are forever
relegated to small (or possibly medium) size projects. Note
that the Linux kernel is, at the MOST, a smallish-medium size project.
> before. So, I don't buy that large project WCs can't scale now.
Been there, done that, made the measurements. If you don't believe me,
then: whatever.
> If you want to tout this based on doing reserved checkouts, fine,
Reserved check-outs are sometimes necessary for workflow reasons (such
as preventing artists editing the same 3dsmax file at the same time) so
it should be _supported_. But that's another feature suggestion that
I'm not prepared to discuss at this time.
> but as far as 'speed improvements' - it's a bad idea. And, as
> I stated, I don't believe reserved checkouts scale. -- justin
It seems to me that you have not yet comprehended the actual suggestion
under consideration. Just as I (and others) said in previous messages:
nobody is talking about reserved check-outs.
Let me re-summarize the suggestion:
+ The problem we're wanting to solve is that it takes 10 minutes to
crawl through 20,000 files, trying to figure out which ones have
changed when you want to commit (or similar).
+ The proposed solution involves keeping local state about which files
have actually been modified, and ONLY look at those files.
+ Because SVN is not the file system, it can't know which files have
been locally modified, so you have to tell it.
+ Therefore, the user can choose on check-out to put all files in read-
only mode, and use "svn edit" to set the writable bit and add the file
to the local list of files-to-examine-when-checking-in.
+ Once a file has been checked in or reverted, the file is removed from
the local edited-files list.
+ Ideally, there is ONE local edited-files list for an entire checked-
out repository, kept conceptually at the root. That way, you don't
even have to crawl the directory tree to find multiple lists of
edited files.
Your argument that if the user says "I want to edit this" he will
automatically also want to lock the file does not hold -- the default
for Perforce is to not lock, and most people are happy with that. You
only lock (totally separate feature) if you really need to.
/ h+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 29 05:45:30 2002