Version caching
Hello, 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.) Is there an add-on or option I can use to ask Subversion to never throw away a version it sees? 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. Cheers. Great product... keep it up! Kevin Hongkong
Re: Version caching
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. -- WBR, Andrey Repin (anrdae...@freemail.ru) 21.11.2010, <18:33> Sorry for my terrible english...
Re: Version caching
On Sun, Nov 21, 2010 at 09:54, Kevin Connor Arpe wrote: > Hello, > > 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.) > > Is there an add-on or option I can use to ask Subversion to never > throw away a version it sees? 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. It sounds like you'd be happier with a DVCS like git or Mercurial. Subversion only caches logs on the client.
Re: Version caching
Andy Levy wrote on Sun, Nov 21, 2010 at 11:14:43 -0500: > Subversion only caches logs on the client. Subversion itself doesn't. I'm told TortoiseSVN does.
Re: Version caching
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.
Re: Version caching
On Sun, Nov 21, 2010 at 9:54 AM, Kevin Connor Arpe wrote: > Hello, > > 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. Not without committing serious database arcanery well below beyond the reach of anyone who has a daytime job and doesn't like trying to outsmart the authors of a system. The basic idea is that every change is permanently logged and never abandoned: Deleting accidents, like somebody committing big old DVD's by accident, turns out to be pretty difficult. > 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.) The normal technique is to use 'svn:externals' to keep particular branches, or tags, checked out for local comparison. Update regularly, and you should be able to do most comparisons far faster. Another possibility is to keep a local mirror, using svnsync, to run your comparisons against. Another possiblity is to acknowledge the difficulty of using such a centralized system as subversion, and switch to git or possibly mercurial. There are some good "gitsvn" gateways that might be helpful. > Is there an add-on or option I can use to ask Subversion to never > throw away a version it sees? That way if I run "log" or "merge" or > "diff" against an older version I have seen before... poof! it is > immediately available. By "older version" I assume you mean "checked out at a different time". > 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. Definitely look at svnsync to maintain a local repository for comparisions. > Cheers. Great product... keep it up! > > Kevin > Hongkong >
