> 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 06:54:24 2002