Johan Corveleyn wrote on Wed, May 02, 2012 at 12:20:35 +0200:
> On Fri, Apr 20, 2012 at 10:52 PM, Stefan Fuhrmann <eq...@web.de> wrote:
> > Am 19.04.2012 14:03, schrieb Johan Corveleyn:
>
> [snip]
>
> >> I haven't read your mail in detail yet, but just a note in passing: in
> >> my experience (with a 1.5 server with FSFS-on-NFS backend) propgetting
> >> ('svnlook propget') every changed file during pre-commit can be very
> >> expensive.
>
> [snip]
>
> > Random thought: is it possible to link the transactions
> > folder to /dev/shm even if the repository is on NFS?
>
> Ah yes, thanks for the suggestion. I should try that someday. Right
> now we're working on moving our repo to a newer server, so it'll take
> me a while to experiment with this.
>
> While we're on the subject: do you know an easy way to do this on
> Windows? It's possible that we'll be moving our server to Windows
> (from Solaris). Not sure yet, it depends on some testing /
> benchmarking.
>
> The reason is that I can probably get faster I/O from our NAS when
> running the server on Windows, because there I can work with iSCSI
> (which is currently not supported by our sysadmins on Solaris). And I
> think iSCSI will get me better performance than NFS (there is also a
> third option: Solaris on ESX, which makes Solaris talk to the storage
> as if it's a local disk (but underlying it's still NFS I think) ...
> don't know whether that makes it faster). To be benchmarked ...
>
> >> - maybe propgetting through one of the bindings is much faster than
> >> through svnlook, and you intend for admins to set this up with some
> >> language bindings? In that case, keep in mind that bindings are not
> >> always installed. Svnlook usually is always there.
> >
> >
> > The problem is probably that svnlook is at a hefty
> > disadvantage over e.g. the server because it has
> > to open the FSFS repo anew for each access. Don't
> > know really what to do about that.
>
> So the only way to get the "relevant property changes" really fast
> with svnlook, would be with a command that gets everything with one
> invocation, I guess.
>
> Actually, there is probably a way to get all those propchanges
> quicker, by parsing the output of 'svnlook diff -t TXN'. But I've not
> done the effort to do that.
>
> Besides, by invoking diff (and discarding the actuall text diffs) a
> lot of needless work is done (and think of those edge cases where our
> internal diff can get really slow), and needless bytes are being
> written/read.
>
> Maybe we'd need a props-only-diff, which gives you only the prop
> changes? In some easily parseable way ...
>
> Another alternative would be to make 'svnlook propget' support
> multiple targets, so you can just propget all paths from 'svnlook
> changed' (possibly trimmed to the Adds and PropMods) in one go.
What about some svnmucc-style interface?
svnmlcc /path/to/repos propget r1 trunk/README svn:eol-style revpropget r1
svn:author propsetf r2 svn:log =(echo danielsh)
This will open one FS handle and won't require a custom script via the
bindings.
