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 delete them. 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.
