[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Mon, 26 Jul 2010 17:30:56 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Monday, July 26, 2010 3:34 PM
> To: svnusertemp_at_href.com
> Cc: dev_at_subversion.apache.org
> Subject: Re: [PATCH] new feature, lazy sync via export --
> skipfilesmatchingsize
>

[snip]

> I don't know if there is interest in providing a feature for svn
export
> which allows exclusions of files from the export based on
user-definable
> criteria (which could include files size). Such a feature might stand
a
> better chance, but would be significantly more work to accomplish.

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-26 18:31:38 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.