I'm actually not against storing a local copy. The way I see it, that's
just a constant overhead factor (linear in size of repository). Anything
that just grows linearly, and in space (not time), is going to be drowned
out by Moore's law sooner or later anyway.
Anyway, if you don't want to store the working copy for all files on the
disk, you could make a writable working copy (and/or save away the original
file) when the user does "svn edit". Then, you could still get diffs and
reverts for free, with no repository access, and the overhead would only
be proportional to the amount of files being edited.
And if you run in the old-skool CVS mode where everything's always open
for edit, you pay the 2x overhead and longer check-in times, which is just
the current status quo.
Cheers,
/ h+
> -----Original Message-----
> From: Kean Johnston [mailto:jkj@caldera.com]
> Sent: Saturday, September 28, 2002 9:38 PM
> To: 'Justin Erenkrantz'; 'Garrett Rooney'
> Cc: 'Jon Watte'; 'Greg Stein'; dev@subversion.tigris.org
> Subject: RE: Eliminating the text-base penalty
>
>
> > 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.
> I agree. But you don't need a local copy of the file to achieve this.
> If on checkout, you record the file properties (date/time/mode/crc)
> in an entries list, that's all you need. With this, you have the
> files all locally, and then an "svn edit" can be a simple matter
> of marking the entries file with a flag that says its been edited.
> At checkin time, all you need to do is scan through each entries
> file in each directory, check for any such flags, and delta in those
> files that have changed. It is useful to store a CRC so that if you
> do an "svn edit", but then change your mind after NOT changing the
> file, you can still "svn revert" to remove the modified flag. When
> you revert, you can compare the CRCs to make sure that the file
> really hasn't changed.
>
> Don't forget my original objection to the notion of cached files
> was how badly it scales. Yes, disk is cheap but not that cheap that
> we should encourage wasting it when perfectly good mechanisms for
> achieving most of the same functionality can be done without
> duplicating every file. About the only thing you CANT do with a
> simple fileprops/CRC mechaism is roll back an already edited file
> without contacting the repository. When your repository is 8 or
> more gigabytes, that's a lot of space "wasted" if everything is
> duplicated.
>
> Kean
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 29 08:16:43 2002