On Jan 4, 2008, at 12:09 AM, Niel De Clerk wrote:
> Good day
> We use SVN over a large distributed network that’s normally slow and
> often unreliable. It has changed our lives drastically though –
> excellent product!
>
> The files that we store in the repository have various types and
> most of them remain unchanged (but it is nice having them there for
> initial deployment to new clients).
> The files in the repository that change regularly all have a .kb
> extension, and the applications running on our clients are mostly
> concerned with these files.
>
> Is it possible to do a “svn status –verbose –show-updates“ that will
> only list the *.kb files (including the ones in sub-directories)?
> I.e. is there a way (direct or workaround) to include a --targets
> switch for a status command? Or a way to ignore files (versioned or
> unversioned) when a certain filter/mask is provided?
What is your repository access method? We tend to need to do
something similar in our usage.
You can do the following:
% svn stat -u -v path1/*.kb path2/*.kb ...
However through profiling we found a performance bottleneck in that it
starts a new repository session (network connection) once for each
target of the command. In our case the problem was with 'svn
update', but I think it applies to almost anything. The performance
became dominated by ~2-3 seconds per target overhead each time it made
a new svn+ssh connection to the server. You can imagine that if this
is done on several thousand files, that it becomes a real drag.
On the other hand, it may be faster to just give it targeted
directories, since it will make one connection for that directory
though it will report status for the entire contents. You can add -N
to prevent this from being recursive too.
> Will this improve the speed of the command execution? (Note this
> will reduce the number of files to consider by more than half)
> I’ve tried to the following syntax c:\myfiles\*.kb, but this seems
> to do a separate transaction for each file and is much slower.
>
> Many thanks
> Niel
>
> This email is subject to our email legal notice, to view click here
Received on 2008-01-04 16:18:42 CET