Is it possible to cache subversion?How to update Subversion the nicest way?Setting up and configuring...
Can I become debt free or should I file for bankruptcy? How do I manage my debt and finances?
Is divide-by-zero a security vulnerability?
How to mitigate "bandwagon attacking" from players?
How can I be pwned if I'm not registered on that site?
Called into a meeting and told we are being made redundant (laid off) and "not to share outside". Can I tell my partner?
Accessing something inside the object when you don't know the key
How to approximate rolls for potions of healing using only d6's?
Are small insurances worth it
What if I store 10TB on azure servers and then keep the vm powered off?
What are these green text/line displays shown during the livestream of Crew Dragon's approach to dock with the ISS?
How would we write a misogynistic character without offending people?
Rationale to prefer local variables over instance variables?
Is there any relevance to Thor getting his hair cut other than comedic value?
"Murder!", said the knight
Did 5.25" floppies undergo a change in magnetic coating?
Avoiding unpacking an array when altering its dimension
What am I? I am in theaters and computer programs
Is my plan for fixing my water heater leak bad?
Why is working on the same position for more than 15 years not a red flag?
A "strange" unit radio astronomy
How can I handle a player who pre-plans arguments about my rulings on RAW?
Make me a metasequence
Why do members of Congress in committee hearings ask witnesses the same question multiple times?
When should a commit not be version tagged?
Is it possible to cache subversion?
How to update Subversion the nicest way?Setting up and configuring Subversion on a linux serversubversion starting as forked processSubversion - Retrieval of mergeinfo unsupportedHow to set max file size for commits in subversionTroubleshooting Subversion performance problemsSubversion cluster / replication / HAMove and Upgrade Subversion serverSubversion on 1 Gb uplinkIs it possible to make nginx cache expires at certain time?
Is it possible to cache subversion at all? May be any commercial solution?
Any help would by highly appreciated.
apache-2.2 svn cache
asked May 28 '13 at 8:36
ALex_hhaALex_hha
5,56711731
bumped to the homepage by Community♦ 12 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
|
show 1 more comment
Is it possible to cache subversion at all? May be any commercial solution?
Any help would by highly appreciated.
apache-2.2 svn cache
asked May 28 '13 at 8:36
ALex_hhaALex_hha
5,56711731
bumped to the homepage by Community♦ 12 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Please clarify the problem you are trying to solve. Do you have a performance problem? If so, how bad? Or do you want to cache for offline use?
– 200_success
May 28 '13 at 9:15
I would also point out that the Apache Subversion module works on top of DAV. DAV authenticates and authorizes every single request, i.e., every file being retrieved duringsvn 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.
– 200_success
May 28 '13 at 9:22
-1 for a lack of initial research, but have a look at Write-Through proxying. Supported since 1.5 (See: svnbook.red-bean.com )
– SmallClanger
May 28 '13 at 9:35
1
@SmallClanger Obviousness to you is a poor reason for down-voting.
– 200_success
May 28 '13 at 9:50
@200_success This wasn't anything to do with obviousness. The FAQ states: "Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much."; and there's a good chapter of the SVN book on proxying. Fair enough, it's not the easiest thing to set up and we'd have welcomed questions on implementation specifics, but there's a reasonable expectation that questioners have done their own research, hence the downvote.
– SmallClanger
May 28 '13 at 15:50
|
show 1 more comment
Is it possible to cache subversion at all? May be any commercial solution?
Any help would by highly appreciated.
apache-2.2 svn cache
asked May 28 '13 at 8:36
ALex_hhaALex_hha
5,56711731
Is it possible to cache subversion at all? May be any commercial solution?
Any help would by highly appreciated.
apache-2.2 svn cache
apache-2.2 svn cache
asked May 28 '13 at 8:36
ALex_hhaALex_hha
5,56711731
asked May 28 '13 at 8:36
ALex_hhaALex_hha
5,56711731
asked May 28 '13 at 8:36
ALex_hhaALex_hha
5,56711731
asked May 28 '13 at 8:36
ALex_hhaALex_hha
5,56711731
asked May 28 '13 at 8:36
ALex_hhaALex_hha
5,56711731
5,56711731
bumped to the homepage by Community♦ 12 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 12 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Please clarify the problem you are trying to solve. Do you have a performance problem? If so, how bad? Or do you want to cache for offline use?
– 200_success
May 28 '13 at 9:15
I would also point out that the Apache Subversion module works on top of DAV. DAV authenticates and authorizes every single request, i.e., every file being retrieved duringsvn 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.
– 200_success
May 28 '13 at 9:22
-1 for a lack of initial research, but have a look at Write-Through proxying. Supported since 1.5 (See: svnbook.red-bean.com )
– SmallClanger
May 28 '13 at 9:35
1
@SmallClanger Obviousness to you is a poor reason for down-voting.
– 200_success
May 28 '13 at 9:50
@200_success This wasn't anything to do with obviousness. The FAQ states: "Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much."; and there's a good chapter of the SVN book on proxying. Fair enough, it's not the easiest thing to set up and we'd have welcomed questions on implementation specifics, but there's a reasonable expectation that questioners have done their own research, hence the downvote.
– SmallClanger
May 28 '13 at 15:50
|
show 1 more comment
Please clarify the problem you are trying to solve. Do you have a performance problem? If so, how bad? Or do you want to cache for offline use?
– 200_success
May 28 '13 at 9:15
I would also point out that the Apache Subversion module works on top of DAV. DAV authenticates and authorizes every single request, i.e., every file being retrieved duringsvn 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.
– 200_success
May 28 '13 at 9:22
-1 for a lack of initial research, but have a look at Write-Through proxying. Supported since 1.5 (See: svnbook.red-bean.com )
– SmallClanger
May 28 '13 at 9:35
1
@SmallClanger Obviousness to you is a poor reason for down-voting.
– 200_success
May 28 '13 at 9:50
@200_success This wasn't anything to do with obviousness. The FAQ states: "Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much."; and there's a good chapter of the SVN book on proxying. Fair enough, it's not the easiest thing to set up and we'd have welcomed questions on implementation specifics, but there's a reasonable expectation that questioners have done their own research, hence the downvote.
– SmallClanger
May 28 '13 at 15:50
Please clarify the problem you are trying to solve. Do you have a performance problem? If so, how bad? Or do you want to cache for offline use?
– 200_success
May 28 '13 at 9:15
Please clarify the problem you are trying to solve. Do you have a performance problem? If so, how bad? Or do you want to cache for offline use?
– 200_success
May 28 '13 at 9:15
I would also point out that the Apache Subversion module works on top of DAV. DAV authenticates and authorizes every single request, i.e., every file being retrieved during
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.– 200_success
May 28 '13 at 9:22
I would also point out that the Apache Subversion module works on top of DAV. DAV authenticates and authorizes every single request, i.e., every file being retrieved during
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.– 200_success
May 28 '13 at 9:22
-1 for a lack of initial research, but have a look at Write-Through proxying. Supported since 1.5 (See: svnbook.red-bean.com )
– SmallClanger
May 28 '13 at 9:35
-1 for a lack of initial research, but have a look at Write-Through proxying. Supported since 1.5 (See: svnbook.red-bean.com )
– SmallClanger
May 28 '13 at 9:35
1
1
@SmallClanger Obviousness to you is a poor reason for down-voting.
– 200_success
May 28 '13 at 9:50
@SmallClanger Obviousness to you is a poor reason for down-voting.
– 200_success
May 28 '13 at 9:50
@200_success This wasn't anything to do with obviousness. The FAQ states: "Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much."; and there's a good chapter of the SVN book on proxying. Fair enough, it's not the easiest thing to set up and we'd have welcomed questions on implementation specifics, but there's a reasonable expectation that questioners have done their own research, hence the downvote.
– SmallClanger
May 28 '13 at 15:50
@200_success This wasn't anything to do with obviousness. The FAQ states: "Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much."; and there's a good chapter of the SVN book on proxying. Fair enough, it's not the easiest thing to set up and we'd have welcomed questions on implementation specifics, but there's a reasonable expectation that questioners have done their own research, hence the downvote.
– SmallClanger
May 28 '13 at 15:50
|
show 1 more comment
4 Answers
4
active
oldest
votes
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?
answered May 28 '13 at 16:00
ALex_hhaALex_hha
5,56711731
add a comment |
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 '13 at 9:13
200_success200_success
4,16011840
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_hha
May 28 '13 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.
– 200_success
May 28 '13 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_hha
May 28 '13 at 12:52
This answer is not an answer to the question posed.
– reinierpost
Feb 2 '17 at 16:16
@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."
– 200_success
Feb 2 '17 at 17:00
add a comment |
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.
answered Feb 2 at 20:52
user61849user61849
1563
add a comment |
You can try to use a HTTP Cache like Squid to cache the HTTP requests.
answered May 28 '13 at 9:09
Fu86Fu86
4131412
1
As far as I know, squid doesn't support caching of svn (dav). Actually it doesn't understand REPORT MERGE MKACTIVITY CHECKOUT and so on.
– ALex_hha
May 28 '13 at 9:32
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f511298%2fis-it-possible-to-cache-subversion%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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?
answered May 28 '13 at 16:00
ALex_hhaALex_hha
5,56711731
add a comment |
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?
answered May 28 '13 at 16:00
ALex_hhaALex_hha
5,56711731
add a comment |
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?
answered May 28 '13 at 16:00
ALex_hhaALex_hha
5,56711731
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?
answered May 28 '13 at 16:00
ALex_hhaALex_hha
5,56711731
answered May 28 '13 at 16:00
ALex_hhaALex_hha
5,56711731
answered May 28 '13 at 16:00
ALex_hhaALex_hha
5,56711731
answered May 28 '13 at 16:00
ALex_hhaALex_hha
5,56711731
5,56711731
add a comment |
add a comment |
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 '13 at 9:13
200_success200_success
4,16011840
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_hha
May 28 '13 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.
– 200_success
May 28 '13 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_hha
May 28 '13 at 12:52
This answer is not an answer to the question posed.
– reinierpost
Feb 2 '17 at 16:16
@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."
– 200_success
Feb 2 '17 at 17:00
add a comment |
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 '13 at 9:13
200_success200_success
4,16011840
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_hha
May 28 '13 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.
– 200_success
May 28 '13 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_hha
May 28 '13 at 12:52
This answer is not an answer to the question posed.
– reinierpost
Feb 2 '17 at 16:16
@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."
– 200_success
Feb 2 '17 at 17:00
add a comment |
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 '13 at 9:13
200_success200_success
4,16011840
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 '13 at 9:13
200_success200_success
4,16011840
edited May 19 '17 at 17:22
answered May 28 '13 at 9:13
200_success200_success
4,16011840
answered May 28 '13 at 9:13
200_success200_success
4,16011840
answered May 28 '13 at 9:13
200_success200_success
4,16011840
4,16011840
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_hha
May 28 '13 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.
– 200_success
May 28 '13 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_hha
May 28 '13 at 12:52
This answer is not an answer to the question posed.
– reinierpost
Feb 2 '17 at 16:16
@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."
– 200_success
Feb 2 '17 at 17:00
add a comment |
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_hha
May 28 '13 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.
– 200_success
May 28 '13 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_hha
May 28 '13 at 12:52
This answer is not an answer to the question posed.
– reinierpost
Feb 2 '17 at 16:16
@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."
– 200_success
Feb 2 '17 at 17:00
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_hha
May 28 '13 at 9:31
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_hha
May 28 '13 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.
– 200_success
May 28 '13 at 10:00
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.
– 200_success
May 28 '13 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_hha
May 28 '13 at 12:52
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_hha
May 28 '13 at 12:52
This answer is not an answer to the question posed.
– reinierpost
Feb 2 '17 at 16:16
This answer is not an answer to the question posed.
– reinierpost
Feb 2 '17 at 16:16
@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."
– 200_success
Feb 2 '17 at 17:00
@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."
– 200_success
Feb 2 '17 at 17:00
add a comment |
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.
answered Feb 2 at 20:52
user61849user61849
1563
add a comment |
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.
answered Feb 2 at 20:52
user61849user61849
1563
add a comment |
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.
answered Feb 2 at 20:52
user61849user61849
1563
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.
answered Feb 2 at 20:52
user61849user61849
1563
answered Feb 2 at 20:52
user61849user61849
1563
answered Feb 2 at 20:52
user61849user61849
1563
answered Feb 2 at 20:52
user61849user61849
1563
1563
add a comment |
add a comment |
You can try to use a HTTP Cache like Squid to cache the HTTP requests.
answered May 28 '13 at 9:09
Fu86Fu86
4131412
1
As far as I know, squid doesn't support caching of svn (dav). Actually it doesn't understand REPORT MERGE MKACTIVITY CHECKOUT and so on.
– ALex_hha
May 28 '13 at 9:32
add a comment |
You can try to use a HTTP Cache like Squid to cache the HTTP requests.
answered May 28 '13 at 9:09
Fu86Fu86
4131412
1
As far as I know, squid doesn't support caching of svn (dav). Actually it doesn't understand REPORT MERGE MKACTIVITY CHECKOUT and so on.
– ALex_hha
May 28 '13 at 9:32
add a comment |
You can try to use a HTTP Cache like Squid to cache the HTTP requests.
answered May 28 '13 at 9:09
Fu86Fu86
4131412
You can try to use a HTTP Cache like Squid to cache the HTTP requests.
answered May 28 '13 at 9:09
Fu86Fu86
4131412
answered May 28 '13 at 9:09
Fu86Fu86
4131412
answered May 28 '13 at 9:09
Fu86Fu86
4131412
answered May 28 '13 at 9:09
Fu86Fu86
4131412
4131412
1
As far as I know, squid doesn't support caching of svn (dav). Actually it doesn't understand REPORT MERGE MKACTIVITY CHECKOUT and so on.
– ALex_hha
May 28 '13 at 9:32
add a comment |
1
As far as I know, squid doesn't support caching of svn (dav). Actually it doesn't understand REPORT MERGE MKACTIVITY CHECKOUT and so on.
– ALex_hha
May 28 '13 at 9:32
1
1
As far as I know, squid doesn't support caching of svn (dav). Actually it doesn't understand REPORT MERGE MKACTIVITY CHECKOUT and so on.
– ALex_hha
May 28 '13 at 9:32
As far as I know, squid doesn't support caching of svn (dav). Actually it doesn't understand REPORT MERGE MKACTIVITY CHECKOUT and so on.
– ALex_hha
May 28 '13 at 9:32
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f511298%2fis-it-possible-to-cache-subversion%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Please clarify the problem you are trying to solve. Do you have a performance problem? If so, how bad? Or do you want to cache for offline use?
– 200_success
May 28 '13 at 9:15
I would also point out that the Apache Subversion module works on top of DAV. DAV authenticates and authorizes every single request, i.e., every file being retrieved during
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.– 200_success
May 28 '13 at 9:22
-1 for a lack of initial research, but have a look at Write-Through proxying. Supported since 1.5 (See: svnbook.red-bean.com )
– SmallClanger
May 28 '13 at 9:35
1
@SmallClanger Obviousness to you is a poor reason for down-voting.
– 200_success
May 28 '13 at 9:50
@200_success This wasn't anything to do with obviousness. The FAQ states: "Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much."; and there's a good chapter of the SVN book on proxying. Fair enough, it's not the easiest thing to set up and we'd have welcomed questions on implementation specifics, but there's a reasonable expectation that questioners have done their own research, hence the downvote.
– SmallClanger
May 28 '13 at 15:50