RE: [PATCH] new feature, lazy sync via export --skipfilesmatchingsize

In viewing the --skipfilesmatchingsize flag as an optimization rather than a filter, perhaps one could take it a step further and incorporate this functionality into the export command itself by default rather than as an option so that the average svn user doesn't have to concern himself/herself with it. I'm thinking that a normal export could skip all unchanged files greater than x MB by default. For those people to whom it is important, there could be some flag provided to change the default threshhold of x MB to whatever they want, passing 0 to have the same effect as the current --skipfilesmatchingsize. This modification would require the computation of a checksum for every file larger than the threshhold. If the default threshhold is set very high then the added overhead would be low for most exports.

--Paul Breen

> -----Original Message-----
> From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
> Subject: RE: [PATCH] new feature, lazy sync via export --skipfilesmatchingsize
> To: dev_at_subversion.apache.org
> Cc: svnusertemp_at_href.com
> Date: Monday, July 26, 2010, 9:30 AM
>
> Did I miss something, but wasn't the original spec "don't
> export files
> that are already on disk". Sure, that's not so far from
> 'don't export
> files based on criteria xyz", but its sufficiently
> different to be
> important.
>
> Ie. This isn't a filter mechanism, it's an optimisation
> designed to
> prevent unnecessary copying of data. Now, it might be that
> the filter
> isn't sufficient to detect whether a file is the same or
> not (and it
> might require timestamp or md5 support too), but I think
> this is a
> valuable option to have. If you have a directory full of
> source files,
> and it contains a sub-directory full of
> almost-never-changing, large
> binary files, then it would be great to initiate an export
> and have it
> recognise the binaries haven't changed and so don't need
> to
> re-downloaded over the top of the existing files.
>
> The flag could be better worded and the algorithm used to
> detect
> un-changed files may need making more robust, but otherwise
> I think it's
> a worthwhile addition. Next - export multiple times into a
> directory
> containing files without deleting any of them :)
>
> Andy
Received on 2010-07-27 03:28:21 CEST