Re: [ANN] SubGit 1.0.0 is released
On Thu, Sep 20, 2012 at 12:13:45AM -0400, Nico Kadel-Garcia wrote: > On Wed, Sep 19, 2012 at 3:34 PM, Alexander Kitaev > wrote: > > Hello All, > > > > Our team is proud and delighted to announce SubGit 1.0.0 release! > > New version is available for download at SubGit web site at > > http://subgit.com/ > > > > SubGit is a server-side tool for a smooth, stress-free Svn to Git > > migration. SubGit lets one to set up a bidirectional Subversion to Git > > replication (writable mirror) and thus it allows users to choose > > freely between Subversion and Git version control systems. > > Except, of course when it doesn't. The use of OS specific EOL, which > git does not support, and subversion keywords like $Id$ and $Author$, > which git does not support, would seem to me to be an adventure > begging to happen. Of course there are problems with trying to do this. But if you're always afraid of running into pitfalls you'll never get anything done. I know you are particularly keen on pointing out pitfalls because you're somebody who often ends up having to work around them professionally, and I sense some love-hate relationship going on here :) We had some very interesting discussions with the Tmate folks when they first announced SubGit at Subversion Day last year: http://www.elegosoft.com/en/company/news/news-in-detail.html?tx_ttnews[pointer]=1&tx_ttnews[tt_news]=114&tx_ttnews[backPid]=195&cHash=f876117be36ef5742b4977d7be07b5da The announcement sparked some interest in German media: http://www.heise.de/developer/meldung/Transparenter-Abgleich-zwischen-Subversion-und-Git-1246894.html My own conviction is that their entire endeavor of rewriting Subversion and related components in Java is outright crazy. But I'm not a Java developer, so maybe I just don't get it. And the quality that Tmate produces is astounding, and the persistence they show with keeping up with Subversion's feature set in SVNKit is highly commendable. Generally, the problem they're tackling with SubGit is a giant compatibility mapping problem between two very different data structures. It is quite interesting to see how much of that problem space they can actually solve, and also how long it has taken them to solve it! One of the developers at Tmate even made this problem part of his thesis. So please, before you dismiss these efforts by pointing out the first minor potential compatibility problem that comes to mind, pay them some respect for their efforts -- they've certainly done their homework around keyword expansion, and lots more.
Re: [ANN] SubGit 1.0.0 is released
On Thu, Sep 20, 2012 at 2:31 AM, Andreas Krey wrote: > On Thu, 20 Sep 2012 00:13:45 +, Nico Kadel-Garcia wrote: > >> Java has its uses. Replacing a full-blown, fully implemented C++ >> codebase where the maintainers, who also set the API's, are all >> working in C++ means entirely different models of file handling, >> memory management, and maintaining compatibility with a dynamic and >> evolving codebase, in another language. > > Sorry, but this is just preemptive bad-mouting. The problem isn't that I think it's justified paranoia, due to concerns about "how are you ever going to keep this reliably in sync with upstream Subversion repository features" ? Subversion 1.8 is due out soon: and the "merge" technology is due for serious revision. Previous major releases of Subversion, with which I'm far more familiar than git, have included all sorts of desirable feature changes such as the switch from default Berkeley DB to FSFS, which seemed a great idea. I'm looking into your docs. That bi-directional, behind the scenes, 2-way communication is *scary*. And you're forcing modifiation of the hook scripts to support this feature set. That would seem to be *begging* for a failed hook script to leave the repositories out of sync. It's necessarily asynchronous, and you may have thought out all the potential issues, but who the heck could tell? It's closed source! > there is no good good implementation of an svn server. The problem is that > the people working on that implementation aren't going to offer any path > that would enable other to integrate a git view on the repository. Heck, That would be a lot of work for a limited benefit when the "git-svn" client tool works pretty well. Given that this toolkit already exists, it's the client access for Subversion clients to > they don't even offer a specified network protocol and insist that > *clients* use the C library. That's not a subject I've personally gotten into. On thought, you have a point: well worth separate review. But that's part of the problem here! By keeping the software an integrated codebase for clients and servers, they're able to make protocol changes that you'll be forced to keep up with in an entirely distinct codebase. How can you *test* that robustly? > So the only way to have a server that is viewable via git and via svn is > to rewrite the server. (Which is also good because the svn repo structure > is, well, suboptimal even for its own pourposes.) And there is obviously > enough public interest/suffering that subgit isn't even the first project > to do so - see svnhub.com. In theory, understandable. But Andreas, SubGit is closed source! Subversion has really, really benefited from the open source licenses. (I'd have preferred GPL to Apache to help prevent that kind of fork, but it certainly wasn't my call.) There are things that would benefit from simultaneous Subversion/Git client access. For example, I'd *love* to use one client for people who have to access both old Subversion repositories at Sourceforge, and git repos at github.com. (I'm publishing the SRPM building tools for Subversion at Github: it's actually a bit embarrassing, but I really need the disconnected development.) > Andreas > > -- > "Totally trivial. Famous last words." > From: Linus Torvalds > Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: [ANN] SubGit 1.0.0 is released
On Thu, Sep 20, 2012 at 06:36:02AM -0400, Nico Kadel-Garcia wrote: > and git repos at github.com. (I'm publishing the SRPM building tools > for Subversion at Github: it's actually a bit embarrassing, but I > really need the disconnected development.) That's not embarrassing. That's using the right tool for the job.
Re: [ANN] SubGit 1.0.0 is released
On Thu, 20 Sep 2012 06:36:02 +, Nico Kadel-Garcia wrote: ... > > I think it's justified paranoia, due to concerns about "how are you > ever going to keep this reliably in sync with upstream Subversion > repository features" ? Like, not at all? (Note: I'm not affiliated with either github or subgit and don't talk for anybody but me.) 1.8 can't afford to drop wire-compatibility with older clients anytime soon, and the availablility of anything that can serve git and svn clients will basically make any more svn updates unneeded. > Subversion 1.8 is due out soon: and the "merge" > technology is due for serious revision. Previous major releases of > Subversion, with which I'm far more familiar than git, have included > all sorts of desirable feature changes such as the switch from default > Berkeley DB to FSFS, which seemed a great idea. That particular switch really shoudn't affekt wire protocol. :-) > I'm looking into your docs. That bi-directional, behind the scenes, > 2-way communication is *scary*. Not mine. What you say sounds more like a marriage of the oritinal servers by hook scripts, now a new server. ... > It's closed source! That's my personal reason not to look into that. :-) If I'd ever go to design something along these lines, I'd forgo the full svn compat and offer only the basic operations for svn clients, so eclipse users and the like are happy, and do the rest on the git level. Especially merging. Im my opinion svn is simply outdated for the types of data I have to deal with (that is, repos that are not going into the gigabytes range), and the only thing that keeps people from massive migration is the need to to interoperate old scripting/tools and the reluctant people who don't actually care much for vesion control and are happy with committing from time to time. As long as the latter chain 'us' to an svn server a migration would be painful. As soon as there is a server that works on git repos and can reasonably talk svn, a lot of switching will occur, as a migration doesn't need to pull them along all the way at once anymore. Perhaps I should put up a kickstarter? :-) ... > That would be a lot of work for a limited benefit when the > "git-svn" client tool works pretty well. Given that this toolkit > already exists, it's the client access for Subversion clients to No, git-svn doesn't unchain you from the svn server, nor can you ever think of redoing your build/deploy in git terms. Most importantly, you're chained to svn's merging - here we begin to check nontrivial merges by trying them in git/git-svn and then seeing whether svn gives us the same results. ... > here! By keeping the software an integrated codebase for clients and > servers, they're able to make protocol changes that you'll be forced > to keep up with in an entirely distinct codebase. How can you *test* > that robustly? That is just shifting the problem. Either you have an API that you can't just modify, or you consider the wire protocol your API, and either way you have to be backwards-compatible and need something to test on that level. (Besides in my opinion the wire protocol is only that complex because you don't replicate - moving whole commits is easier than doing all the commands remotely.) > In theory, understandable. But Andreas, SubGit is closed source! > Subversion has really, really benefited from the open source licenses. Strong Ack. I wouldn't even look into github's svn access for serious stuff for the same reason. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: [ANN] SubGit 1.0.0 is released
Guten Tag Andreas Krey, am Donnerstag, 20. September 2012 um 13:35 schrieben Sie: > Im my opinion svn is simply outdated for the types of data I have to deal > with (that is, repos that are not going into the gigabytes range), and > the only thing that keeps people from massive migration is the need to > to interoperate old scripting/tools and the reluctant people who don't > actually care much for vesion control and are happy with committing > from time to time. As long as the latter chain 'us' to an svn server a > migration would be painful. As soon as there is a server that works on > git repos and can reasonably talk svn, a lot of switching will occur, > as a migration doesn't need to pull them along all the way at once anymore. I maybe misunderstand your argumentation but the only thing I read over and over again is: Use git, it's superior. Not that I'm surprised, it's the same argument I read a dozens of times in each and every discussion about git vs. Subversion, but you could save a lot of time if you wouldn't package this small sentence in this much text. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: [ANN] SubGit 1.0.0 is released
On Thu, Sep 20, 2012 at 01:35:26PM +0200, Andreas Krey wrote: > and the availablility of anything that can serve git and svn > clients will basically make any more svn updates unneeded. To be frank, that attitude is just as short-sighted and destructive to the open source community as is Lennart's crusade in Linux-land to force everyone on the planet onto his systemd via redhat's giant hand of influence. (They've been trying to tie projects like GNOME onto systemd as a hard dependency -- systemd will only ever run on Linux which means this would limit people's choices.) There are different projects that fulfill different needs, and we should strive to keep them alive for as long as they serve a useful purpose to their users. Users should freely be able choose between tools and benefit from improvements made to each tool. In the grand scheme of things, the development of git is entirely orthogonal to the development of Subversion. They're different tools made for different requirements.
Re: UNS: Re: [ANN] SubGit 1.0.0 is released
On Thu, 20 Sep 2012 14:27:20 +, Stefan Sperling wrote: > On Thu, Sep 20, 2012 at 01:35:26PM +0200, Andreas Krey wrote: > > and the availablility of anything that can serve git and svn > > clients will basically make any more svn updates unneeded. > > To be frank, that attitude is just as short-sighted and destructive > to the open source community as is Lennart's crusade in Linux-land Oh, I didn't mean that svn1.8 would be unnecessary; I meant that a server working with git and svn clients would generally be a migrational tool and wouldn't need to follow svn. I recognise that there are use cases for svn, I just don't have any around here. ... > There are different projects that fulfill different needs, and we > should strive to keep them alive for as long as they serve a useful > purpose to their users. Users should freely be able choose between > tools and benefit from improvements made to each tool. Systemd has the same problem as svn/git. They are not per-user decisions but need to be made on a more global scale. > In the grand scheme of things, the development of git is entirely > orthogonal to the development of Subversion. They're different tools > made for different requirements. ...with the problem that a lot of svn uses were decided back when git wasn't known/available but git would be the proper tool now, were it not for migration effort. subgit would lower that barrier. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: [ANN] SubGit 1.0.0 is released
On Thu, 20 Sep 2012 14:18:11 +, Thorsten Schöning wrote: ... > I maybe misunderstand your argumentation but the only thing I read > over and over again is: Use git, it's superior. Well, it is. :-) [As I said, in my domain but I think not just in my opinion.] But I was discussing why that meant some of the critics against subgit and similar tools are simply not applicable. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
svn checkout problem with http address
Hi, I am new subversion user. I installed subversion in the ubuntu linux yesterday, but I cannot get it to work with http address. The "svn co" command will result in a timeout error after an hour. I have done some tests on my computer. I can do "svn co" with https and svn address, e.g. svn://svn.openttd.org/trunk. But for http address, there is a problem. I can see the directory and files using a browser, e.g. http://svn.openttd.org/trunk, but "svn co" does not work. Also I tried to "svn co" on another machine and network for the same address, and it worked fine. Can anybody help me with that issue? Thank you.
Re: [ANN] SubGit 1.0.0 is released
On Thu, Sep 20, 2012 at 4:35 AM, Andreas Krey wrote: > On Thu, 20 Sep 2012 06:36:02 +, Nico Kadel-Garcia wrote: >> here! By keeping the software an integrated codebase for clients and >> servers, they're able to make protocol changes that you'll be forced >> to keep up with in an entirely distinct codebase. How can you *test* >> that robustly? > > That is just shifting the problem. Either you have an API that you can't > just modify, or you consider the wire protocol your API, and either way > you have to be backwards-compatible and need something to test on that > level. (Besides in my opinion the wire protocol is only that complex > because you don't replicate - moving whole commits is easier than doing > all the commands remotely.) It's worth pointing out that this problem isn't that big of a problem for them. If they implement one version of our wireline protocol then they are going to interoperate with us until we bump the major. Yes they may be missing some features until they catch up, but they will interoperate.
Commit - 500 Internal Server Error in response to POST request
Guys,
I've been beating my head against a wall for the last several days trying to
figure this out. I'm moving my SVN repo to a new server. Shouldn't be too
big a deal. I made the data dump, transferred it to my new server, installed
svn v1.7.6, created the repo and imported the data dump into the new repo.
No problem at all. In fact, I can browse to the repo and view all of the
files. However, when I try to create a directory or commit changes to the
new repo, I get this error message:
Commit failed: Server sent unexpected return value (500 internal server
error) in response to POST request for '/repos/!svn/me'
I've thought it was a permissions issue, so I've tried every kind of
user:group combo that I can and even given 777 permissions to the SVN repo
folder and contents but to no avail. I've assigned nobody:nobody,
username:nobody, and username:username but no user:group combo seems to
work. For the life of me, I can't figure it out. Let me give some info about
my system.
Centos 5.8
WHM/cPanel 11.32.4
Apache 2.2.22
Subversion v1.7.6
I am attempting to run the svn from a subdomain: nat.domainname.com/repos
but I'm failing miserably. Here are the pertinent config files
httpd.conf
ServerName nat.domainname.com
ServerAlias www.nat.domainname.com
DocumentRoot /home/username/public_html/svn
ServerAdmin webmas...@nat.domainname.com
UseCanonicalName Off
CustomLog /usr/local/apache/domlogs/nat.domainname.com combined
CustomLog /usr/local/apache/domlogs/nat.domainname.com-bytes_log "%{%s}t
%I .\n%{%s}t %O ."
## User username # Needed for Cpanel::ApacheConf
suPHP_UserGroup username username
SuexecUserGroup username username
RUidGid username username
ScriptAlias /cgi-bin/ /home/username/public_html/svn/cgi-bin/
DAV svn
SVNPath /home/username/svn
#AuthType Digest
#AuthName "Integrity SVN"
#AuthUserFile /home/username/.htpasswds/passwd
#Require valid-user
I'm also including the info from my access_log and error_log for this
ERROR_LOG
[Thu Sep 20 00:17:14 2012] [error] [client 192.168.0.105] Request exceeded
the limit of 10 internal redirects due to probable configuratio$
[Thu Sep 20 00:17:14 2012] [debug] core.c(3112): [client 192.168.0.105]
r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /repos/!svn/me
[Thu Sep 20 00:17:14 2012] [error] [client 192.168.0.105] Request exceeded
the limit of 10 internal redirects due to probable configuratio$
[Thu Sep 20 00:17:14 2012] [debug] core.c(3112): [client 192.168.0.105]
r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/username/public_html/index.php
[Thu Sep 20 00:17:14 2012] [debug] core.c(3118): [client 192.168.0.105]
redirected from r->uri = /home/use
RE: Commit - 500 Internal Server Error in response to POST request
David, You hit on the problem actually. "The first obvious question is whether the .so files that Apache sees are for 1.7.6. Your CentOS distribution comes with an older version already installed; you need to replace that in its entirety." Since this is an WHM/cPanel server, I have to use EasyApache to compile Apache. I assumed that their Mod_Dav module would work with SVN 1.7.6. Thus, I deleted all vestiges of SVN and recompiled SVN v1.6.18, rebuilding the repos. Lo and behold, I can commit now. So there we have it, Subversion 1.7.6 doesn't seem to be compatible with WHM's Apache v2.2.22. Now I'll have to recheck out some repositories, but at least it's working! I should have thought of this earlier. Thanks for pointing me in the right direction! Mitchell Killian From: David Chapman [mailto:dcchap...@acm.org] Sent: Thursday, September 20, 2012 5:26 PM To: Mitchell Killian Subject: Re: Commit - 500 Internal Server Error in response to POST request On 9/20/2012 2:19 PM, you wrote: Guys, I've been beating my head against a wall for the last several days trying to figure this out. I'm moving my SVN repo to a new server. Shouldn't be too big a deal. I made the data dump, transferred it to my new server, installed svn v1.7.6, created the repo and imported the data dump into the new repo. No problem at all. In fact, I can browse to the repo and view all of the files. However, when I try to create a directory or commit changes to the new repo, I get this error message: Commit failed: Server sent unexpected return value (500 internal server error) in response to POST request for '/repos/!svn/me' I've thought it was a permissions issue, so I've tried every kind of user:group combo that I can and even given 777 permissions to the SVN repo folder and contents but to no avail. I've assigned nobody:nobody, username:nobody, and username:username but no user:group combo seems to work. For the life of me, I can't figure it out. Let me give some info about my system. I'm swamped, so I don't have time for analysis (and comparison of your Apache setup to mine), but the first obvious question is whether the .so files that Apache sees are for 1.7.6. Your CentOS distribution comes with an older version already installed; you need to replace that in its entirety. The other thing to try is create a very small test repository (empty is probably sufficient since you are having problems with commits), then define a minimal Apache installation with as few features as possible: no hook scripts, no virtual hosts, no extra modules, etc. If you get the same errors on a bare-metal Apache/Subversion server configuration, it will be much easier for people to help. Otherwise you have to hope that someone had exactly the same configuration as you and can point directly at the issue. It seems like you have a redirection problem; I'd look at the interaction between DocumentRoot and SVNPath. My non-VirtualHost DocumentRoot points to a completely unrelated directory; the DocumentRoot in my Subversion VirtualHost points to an empty directory. Only the SVNPath directory points to a non-empty directory - the repository itself. I believe you need to ensure that you don't point Subversion requests at the same directory (or a subdirectory) as your DocumentRoot. Your edited httpd.conf and log files might hide interactions between these two variables, making it hard for someone to analyze. (This is another reason why small test repositories are so nice - no editing required to remove proprietary data.) Good luck! -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: [ANN] SubGit 1.0.0 is released
On Thu, Sep 20, 2012 at 12:44 PM, Ben Reser wrote: > On Thu, Sep 20, 2012 at 4:35 AM, Andreas Krey wrote: >> On Thu, 20 Sep 2012 06:36:02 +, Nico Kadel-Garcia wrote: >>> here! By keeping the software an integrated codebase for clients and >>> servers, they're able to make protocol changes that you'll be forced >>> to keep up with in an entirely distinct codebase. How can you *test* >>> that robustly? >> >> That is just shifting the problem. Either you have an API that you can't >> just modify, or you consider the wire protocol your API, and either way >> you have to be backwards-compatible and need something to test on that >> level. (Besides in my opinion the wire protocol is only that complex >> because you don't replicate - moving whole commits is easier than doing >> all the commands remotely.) > > It's worth pointing out that this problem isn't that big of a problem > for them. If they implement one version of our wireline protocol then > they are going to interoperate with us until we bump the major. Yes > they may be missing some features until they catch up, but they will > interoperate. Except that it can't be merely wire protocol. They're remapping the commit, copy, delete, move,branch, tag, and merge operations of one source control into the other. That's. not directly comparable, especially the tag operation, which is really designed to be much more locked down than Subversion has by default. In theory, I suppose you could lock it down to emulate the git "thou shalt not touch me" model. And unfortunately, there are Subversion usage models that simply don't map well to the standard trunk/branches/tags layout, such as matching simultaneous tags for source code and/or binaries of multiple parallel projects in the same repository.
Re: [ANN] SubGit 1.0.0 is released
On Thu, Sep 20, 2012 at 8:31 PM, Nico Kadel-Garcia wrote: > Except that it can't be merely wire protocol. They're remapping the > commit, copy, delete, move,branch, tag, and merge operations of one > source control into the other. That's. not directly comparable, > especially the tag operation, which is really designed to be much more > locked down than Subversion has by default. In theory, I suppose you > could lock it down to emulate the git "thou shalt not touch me" model. > > And unfortunately, there are Subversion usage models that simply don't > map well to the standard trunk/branches/tags layout, such as matching > simultaneous tags for source code and/or binaries of multiple parallel > projects in the same repository. Just because there are use cases that you can see that it doesn't cover doesn't mean it's not useful for someone. In this particular case it's like complaining that a bicycle isn't very useful in getting across the Atlantic and using that as an argument that nobody should make bicycles. I'm not going to bother responding to this thread further. It really has no place on the d...@subversion.apache.org or users@subversion.apache.org list as Brane has wisely pointed out.
Strange 403 forbidden problem on SVN!
Hi, I got 403 forbidden error when I tried to checkout a repository(say A) using my account on my PC. But on my colleague’s PC, my account works well. Meanwhile, I can checkout another repository (say B, another project on the same svn-server with A) on my PC. I am sure that I input the username and password properly. And repository owner is also sure that I have the access permission to both A and B. What kind of issue could this be? It’s really strange, and I can’t find any clue. Would you help me out? Thanks. Best regards -Tao Chen
Re: svn checkout problem with http address
On Sep 20, 2012, at 10:43, Jing Jin wrote: > I am new subversion user. I installed subversion in the ubuntu linux > yesterday, but I cannot get it to work with http address. The "svn co" > command will result in a timeout error after an hour. > > I have done some tests on my computer. I can do "svn co" with https and svn > address, e.g. svn://svn.openttd.org/trunk. But for http address, there is a > problem. I can see the directory and files using a browser, e.g. > http://svn.openttd.org/trunk, but "svn co" does not work. > > Also I tried to "svn co" on another machine and network for the same address, > and it worked fine. > > Can anybody help me with that issue? Perhaps your network has a proxy server that doesn't understand WebDAV HTTP methods. You could talk to your network administrator about fixing the proxy server. Or if available you could use HTTPS since a proxy can't mangle encrypted traffic.
Re: Commit - 500 Internal Server Error in response to POST request
On 9/20/2012 2:19 PM, Mitchell Killian wrote: Guys, I've been beating my head against a wall for the last several days trying to figure this out. I'm moving my SVN repo to a new server. Shouldn't be too big a deal. I made the data dump, transferred it to my new server, installed svn v1.7.6, created the repo and imported the data dump into the new repo. No problem at all. In fact, I can browse to the repo and view all of the files. However, when I try to create a directory or commit changes to the new repo, I get this error message: Commit failed: Server sent unexpected return value (500 internal server error) in response to POST request for '/repos/!svn/me' I've thought it was a permissions issue, so I've tried every kind of user:group combo that I can and even given 777 permissions to the SVN repo folder and contents but to no avail. I've assigned nobody:nobody, username:nobody, and username:username but no user:group combo seems to work. For the life of me, I can't figure it out. Let me give some info about my system. Centos 5.8 WHM/cPanel 11.32.4 Apache 2.2.22 Subversion v1.7.6 Following up to the list: I suggested he look for a version mismatch between the installed DAV .so files and the new Subversion executables (i.e. that he may need to install new DAV .so files as well), and that turned out to be the case. He has reverted to Subversion 1.6.18 for the time being. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
