Is it possible to cache subversion at all? May be any commercial solution?
Any help would by highly appreciated.
4 Answers
The context of your question is unclear, but I would suggest using git-svn instead of Subversion. The git-svn bridge gives you an interface and user experience like Git, while retaining Subversion as the official repository. Basically, you start by running git svn clone URL, which creates a local Git repository that contains the entire repository history, with some Subversion metadata so that you can resynchronize later. The Subversion repository is treated by Git as a special kind of remote repository. Git-svn has multiple advantages over the usual Subversion workflow:
- Git is simply a more powerful tool than Subversion.
- Operations that Subversion would normally query the server for, such as
svn log, happen locally.git logis much faster thansvn log. (If you want the output to look likesvn log, then rungit svn loginstead.) - You have the option to make local Git branches, commit to them, rewrite history in them, etc., before pushing them into the remote Subversion repository.
- Road warriors can work offline except when syncing.
The main caveats are:
- Git is more difficult to learn than Subversion.
- The multiple steps to commit (
git commit -afollowed bygit svn dcommit) can be confusing to some users. - Some Subversion concepts are not well supported. For example, Git does not handle keyword expansion well.
- Subversion lets you check out portions of a repository, whereas Git operations always work on the entire repository. If your Subversion repository has per-directory access control, then git-svn won't work well.
answered May 28, 2013 at 9:13
-
I have a slow (actually very slow) ISP uplinks. 10 and 20 Mbps. At the same time project in svn are very "heavy" ~500-800 Mbyte. We can't use git at all.– ALex_hhaMay 28, 2013 at 9:31
-
If the size of your repository dwarfs the transfer rate of your connection, will caching really solve your problem? Subversion is inefficient in two ways: many operations require server connectivity, and branching is accomplished by file duplication. Consider ditching Subversion in favor of a distributed VCS such as Git, which avoids both performance problems. Alternatively, consider moving to a Subversion hosting service. May 28, 2013 at 10:00
-
Yes, I think caching is solving my problem. Because in our repositories there are a lot of big zip/psd files and moving to hosting service doesn't solve issue at all. And that's why we can't move to git– ALex_hhaMay 28, 2013 at 12:52
-
-
@reinierpost In case it isn't clear, my answer is "no, I don't think you can cache Subversion, because that's not how the protocol works, but you can use Git to achieve your goal." Feb 2, 2017 at 17:00
I have found interesting info http://www-01.ibm.com/support/docview.wss?uid=swg21217781
Supported methods:
WebDAV methods (defined in RFC 2518):
PROPFIND , PROPPATCH , MKCOL, COPY, MOVE, LOCK, UNLOCK, SEARCH
Does anyone tried run subversion via ibm proxy server?
A very general commercial solution is a product offering from Riverbed Technology. To my understanding, it's deployed at the data center and at remote site offices and watches all network traffic, on which it calculates checksums at a block-by-block (?) level.
In the data-center-outbound case (e.g., a central Subversion server), when it sees outbound traffic that matches a previous checksum, it sends just the checksum over the WAN, which the remote office's device looks up, decompresses, and transmits the corresponding data block on its LAN. I've heard of this used in multiple companies to improve site office network speeds.
svn checkout. If you use htpasswd-based authentication, it works fast enough. If you use mod_authnz_ldap, that's also OK, since it caches authentication results. However, if your authentication works through some other module, such as PAM, and you aren't using the authentication caching mechanism introduced in Apache 2.4, then the performance hit is brutal.