Thanks Ryan.
So is there any plan to implement this feature in svn in the future or as you said since subversion is designed for low bandwidth situations, the developers are not going to do it.?
Hi Bob,
As Ryan explained when I meant data caching, i mean the client has to contact the repository everytime we do svn update, svn commit etc.. which might be a hit on the network bandwidth. Instead of contacting the repository evrytime, we can get the file changes from the cache which lies on the same machine/filesystem
I am not talking of client credentials/password caching etc
thanks
Ashish
--- On Wed, 12/3/08, Ryan Schmidt <subversion-2008c_at_ryandesign.com> wrote:
> From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
> Subject: Re: Data caching functionality for subversion
> To: aputagikar_at_yahoo.com
> Cc: users_at_subversion.tigris.org
> Date: Wednesday, December 3, 2008, 3:55 PM
> On Dec 2, 2008, at 17:09, Ashish Utagikar wrote:
>
> > Does anybody know whether subversion has any
> data caching functionality. By data caching, I mean the data
> is cached in the cache area so that the the client does not
> have to contact the server every time and it can get its
> data from the cache which usually resides on the same
> machine/file system as the client.
> >
> > Many tools like Design Sync, SOS etc have this
> functionality.
> >
> > Right now it looks like the client has to contact the
> server everytime which might reside on the remote machine
> during the update
>
> It depends on the command. Subversion is designed to be
> used in low-bandwidth situations so yes certainly some
> information is cached in the working copy. For example, the
> .svn directory inside every directory in your working copy
> contains a pristine copy of all the files and their
> properties, so that if you want to see what you've
> changed, "svn diff" does not have to (and does
> not) contact the repository. Same with "svn
> status".
>
> Other commands do contact the repository. "svn
> update" gets changes from the repository and "svn
> commit" sends your changes to the repository so those
> clearly contact the repository. "svn log" gets the
> log from the repository; the log is not cached locally
> presumably because it could be changed after the fact if a
> pre-revprop-change hook is installed to permit that, and
> because the log might be rather large. "svn blame"
> contacts the server because it has to go through the entire
> history of the file and that's not stored locally.
>
> Have you read the book? It might explain more about this.
>
> http://svnbook.org/
>
>
> Note that svk is an alternative to svn, built on top of the
> svn libraries, and that it in fact keeps an entire copy of
> the repository locally, instead of using .svn directories in
> your working copy. I have not used svk, but I believe this
> means you can ask for log information, blame information,
> and even do commits without having access to the master
> repository. svk is compatible with regular svn repositories.
> For more info:
>
> http://svk.bestpractical.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=979222
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2008-12-04 16:05:35 CET