In Subversion 1.7, text-bases are stored in a SHA-1-keyed store (as
opposed to a pathname-based store in 1.6 and earlier), and the "old"
text-base aren't always removed as soon as there is no working copy file
corresponding to them. (I tried committing a file in one wc and
updating that file in another wc; both wc's retained both text-bases.)
If the code is smart enough to not re-fetch something it has the text-base
for already, then your task boils down to changing Subversion's "when to
delete a text-base" policy (so as to make it keep more text-bases even
if they aren't referred to by any current file).
None of the above addresses log messages; however, for that you could
use other solutions. One way is to enable commits mails and never
Andrey Repin wrote on Sun, Nov 21, 2010 at 18:36:20 +0300:
> Greetings, Kevin Connor Arpe!
> > I have a question about version caching. I am using the latest
> > (stable) version on both Linux and WinSlows.
> > As I understand Subversion, once a version is committed, basically it
> > can never changed. A version is written in stone.
> > If that is true, I was hoping Subversion could cache each versioned
> > copy that it downloads. Currently, it seems running "log", "diff",
> > and "merge" takes quite some time (I am very far away from my
> > Subversion server at work... half the world.)
> I strongly suggest you read http://svnbook.org/ before asking any questions
> about Subversion.
> > Is there an add-on or option I can use to ask Subversion to never
> > throw away a version it sees?
> For this your question, there's two answers, equally right.
> 1. It is a native property of a Subversion.
> 2. It's not possible, nor it is realistically applicable.
> > That way if I run "log" or "merge" or "diff" against an older version I have
> > seen before... poof! it is immediately available.
> > I thought about mirroring the server in read-only mode, but I really
> > just want a local cache for versions that I might be looking at.
> That's the same.
Received on 2010-11-21 17:10:50 CET