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

Re: Merge policies

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 2 May 2012 12:20:35 +0200

On Fri, Apr 20, 2012 at 10:52 PM, Stefan Fuhrmann <eqfox_at_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.

-- 
Johan
Received on 2012-05-02 12:21:32 CEST

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