Re: E175012 and E175002 when trying to commit
On Tue, Apr 2, 2019 at 10:20 PM Daniel Shahaf wrote:
>
> Christoph Vogtländer wrote on Tue, 02 Apr 2019 09:02 +00:00:
> > This is reproducible. Running with de_DE.UTF-8 (my default LANG), svn
> > will try to submit the change but runs into a time-out. Running with
> > en_GB.UTF-8, svn fails with error 413.
> >
> > Why is subversion acting differently with different language setting on
> > the client side?
> >
>
> I'm not sure, especially given that both locales are UTF-8 ones.
Perhaps the difference between your first and second attempt is not
caused by different language settings, but because the working copy
was in a different state? For instance, if the "base" of your working
copy is full of mixed revisions, and you're committing a lot of
changes on top of that, the "edit report" that's sent by the client to
the server can be much larger (thus hitting some limit on the server).
Maybe try to execute another 'svn update' on your entire working copy
so it gets a uniform revision.
> A few
> shots in the dark:
>
> - Try '-F /dev/null' instead of '-F svn-commit.tmp'.
> - Is there any non-ASCII in the output of `svn st -q`? (`svn st -q | sed
> 's/[ -~]//g' | grep .`; that's left bracket, space, minus, tilde, right
> bracket)
> - Try LC_ALL=C and LC_ALL=C.UTF-8.
>
> > Any ideas what can be done to successfully commit the changes?
>
> Depends. If you want to make the changes in one commit, you'll need to
> increase the timeouts in server and client sufficiently (that includes
> any proxies). A workaround is to separate the changes to several
> commits: use 'svn commit -- ./foo ./bar' instead of 'svn commit -- ./'.
Just another hint to get you started: the client-side timeout can be
found in the file ~/.subversion/servers on your client machine. Look
for "http-timeout = ..." (the default is 60 (seconds) I believe).
Also, on the server-side, the httpd directive LimitXMLRequestBody
might be playing a role in that second error ("Request Entity Too
Large"). In our setup at work we have "LimitXMLRequestBody 0" in our
httpd config, to effectively have no limit (for a publicly exposed
repository you should always have some limit, to avoid malicious users
being able to crash your server, but if you only have internal users I
think it's OK to eliminate that limit).
Though I would seriously recommend splitting up your huge commit into
several commits. Perhaps find some logical blocks, or split by
subdirectories, or ... Huge commits can be a pain later on, for
instance because every time you query the 'svn log' for one of those
files later, this huge commit will be part of the result (part of its
history), and with the '-v' (verbose) option 'svn log' will show all
the affected paths, which will be huge ...
> I'm not sure why you'd get a 413 on the request to !svn/me, though. (to
> the list) Are any requests made to !svn/me other than the initial POST?
Sorry, no idea.
--
Johan
AW: E175012 and E175002 when trying to commit
> Von: Johan Corveleyn [mailto:jcor...@gmail.com] > Gesendet: Mittwoch, 3. April 2019 10:18 > Perhaps the difference between your first and second attempt is not > caused by different language settings, but because the working copy > was in a different state? For instance, if the "base" of your working > copy is full of mixed revisions, and you're committing a lot of > changes on top of that, the "edit report" that's sent by the client to > the server can be much larger (thus hitting some limit on the server). > Maybe try to execute another 'svn update' on your entire working copy > so it gets a uniform revision. No, I don't think so. I'm using a fresh check-out on the branch, there should be no mixed revisions. And this issue is reproducible. Running with de_DE.UTF-8 will always try to send the data, using en_GB.UTF-8 will fail straight away with 'Request Entity Too Large' error. I run these commands in the same local working copy. Nothing else in between (like cleanup etc.) > Just another hint to get you started: the client-side timeout can be > found in the file ~/.subversion/servers on your client machine. Look > for "http-timeout = ..." (the default is 60 (seconds) I believe). Nothing set on the client side. The server defines a timeout of 300. When using de_DE.UTF-8 the commit fails after over 90 Minutes. So this settings does not seem to be related. But, I will try to increase the timeout and check if that helps. > Though I would seriously recommend splitting up your huge commit into > several commits. Perhaps find some logical blocks, or split by > subdirectories, or ... Huge commits can be a pain later on, for > instance because every time you query the 'svn log' for one of those > files later, this huge commit will be part of the result (part of its > history), and with the '-v' (verbose) option 'svn log' will show all > the affected paths, which will be huge ... Unfortunately, this is an import from 3rd party. So, there are no logical blocks. I might be able to commit on sub-folder after the other. But, I need to merge this into trunk later which will then be a lot of hassle and error prone. I will try to commit in a single commit after adapting the server configuration (Timeout, LimitXMLRequestBody), first. Sigma Surface Science GmbH, Idsteiner Str. 78, 65232 Taunusstein. Amtsgericht Wiesbaden, HRB 27422. Geschäftsführer: Norbert Nold
[no subject]
Hello all, I've been happily managing an svnserve server for a while now. Recently, I've decided to try Collabnet's Subversion Edge, to see if it would make administration easier, and because I'm interested in trying out LDAP later. However, performance is abysmal : any client operation takes a long time, and makes httpd consume a *lot* of CPU while the request is processed. Opening TortoiseSVN's repobrowser consumes 100% of all 6 cpu cores of the server for 5 to 20 seconds. It also happens, though not as much, with an empty repository (just empty trunk/branches/tags directories). If I do the same tests with svnserve, the cpu usage is barely noticeable. I found posts about a similar cpu issue caused by LDAP, but it's not enabled, so the suggested solution (setting LDAPSharedCacheSize to 0) doesn't work. I'm not sure if this is the right place to ask, as a lot of components are involved, so feel free to redirect me elsewhere. There's probably something wrong in my setup, but having no Apache experience, I'm not sure how to diagnose it. Any help is appreciated. The server is a 6 cores VM running Windows Server 2012 R2. I did a default install of Subversion Edge 5.2.3. I accessed the repository with TortoiseSVN 1.11.0 and 1.11.1, both remotely and locally, with http and https. Julien Cugnière
AW: E175012 and E175002 when trying to commit
> Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Gesendet: Dienstag, 2. April 2019 22:20 > I'm not sure, especially given that both locales are UTF-8 ones. A few > shots in the dark: > > - Try '-F /dev/null' instead of '-F svn-commit.tmp'. This will fail with E175012 (but with different "details"): svn: E175012: Übertragen schlug fehl (Details folgen): svn: E175012: Die Wartezeit für die Verbindung ist abgelaufen svn: E200042: Zusätzliche Fehler: svn: E175002: Unerwarteter Serverfehler 500 »Internal Server Error« auf »/svn/ThirdParty/!svn/txn/914-pj« On the server I get: Could not open specified transaction. [500, #160014] Reference to non-existent node '0.0.t914-pj' in filesystem 'D:/Repositories/ThirdParty/db' [500, #160014] > - Is there any non-ASCII in the output of `svn st -q`? (`svn st -q | sed > 's/[ - > ~]//g' | grep .`; that's left bracket, space, minus, tilde, right bracket) This exists with exit code 1. So I assume there are no non-ASCII character? > - Try LC_ALL=C and LC_ALL=C.UTF-8. $> LC_ALL=C svn ci -F svn-commit.tmp . svn: E175002: Commit failed (details follow): svn: E175002: Unexpected HTTP status 413 'Request Entity Too Large' on '/svn/ThirdParty/!svn/me' $> LC_ALL=C.UTF-8 svn ci -F svn-commit.tmp . svn: warning: cannot set LC_CTYPE locale svn: warning: environment variable LC_ALL is C.UTF-8 svn: warning: please check that your locale name is correct svn: E175002: Commit failed (details follow): svn: E175002: Unexpected HTTP status 413 'Request Entity Too Large' on '/svn/ThirdParty/!svn/me' On the server I get: Request body is larger than the configured limit of 800 Error parsing skel POST request body. [413, #175002] > > Any ideas what can be done to successfully commit the changes? > > Depends. If you want to make the changes in one commit, you'll need to > increase the timeouts in server and client sufficiently (that includes > any proxies). A workaround is to separate the changes to several > commits: use 'svn commit -- ./foo ./bar' instead of 'svn commit -- ./'. I'd rather want to commit in a single commit. I also need to merge this change into trunk and commit there as well. Most likely I will run into this issue again, later. The "800" seems to refer to the "LimitXMLRequestBody" property in httpd.conf. I increased the " LimitXMLRequestBody" to 3200 in httpd-custom.conf. The transaction was committed successfully using LC_ALL=C. But, the client still exited with a time-out. I solved this by reverting and updating the working copy. I will try to increase the parameter "Timeout" as well to see if this makes any difference for the client. I will also try to use de_DE.UTF-8 after merging into to trunk to see if this is now working as well. So it seems the behaviour using local C or en_GB.UTF-8 is working correctly (checking the request body size before starting the commit) whereas using de_DE.UTF-8 does not seem to check correctly resulting in a transaction failure. Sigma Surface Science GmbH, Idsteiner Str. 78, 65232 Taunusstein. Amtsgericht Wiesbaden, HRB 27422. Geschäftsführer: Norbert Nold
Re: Add changes from a local svn repo to the same but older repo on a server with history
On Tue, Apr 2, 2019 at 10:08 PM wrote: > > On 04/01 09:23, Eric Johnson wrote: > > Hi mcc, > > > > On Mon, Apr 1, 2019 at 5:40 AM wrote: > > > > > Hi, > > > > > > (I am not subscribed and appreciate to be CC:ed by any reply to my > > > question. Thank you! :) ) > > > > > > The setup is some freaking weired and I am no native speaker... > > > > > > The setup: There is a remote SVN-server, I can only access via PC "A" > at > > > place "A". > > > I am working, compiling, developing at PC "B" at place "B". > > > Changeing places and PCs is hmmm ... "less effective" > > > hrrrmmm. > > > > > > I am working with repo "A" on the SVN-Server. > > > > > > > Quite the unpleasant setup > > > > > > > > > > To be able to check in changed sources not only at the beginning of the > > > project and at > > > the end of the project but in logically reasonable portions I came > > > accross an idea... > > > from which I dont know whether it works or not > > > > > > 1) Export the repo "A" from the server. > > > > > > > svnrdump > > > > > > > 2) Create an empty local repo of the same structure. > > > > > > > svnadmin create > > > > > > > 3) Import the sources into the local repo at PC "B" > > > > > > > svnadmin load > > > > > > > 4) Check in logically sized portioned into the local repo. > > > > > > > svn add, svn commit , ... > > > > 5) If completed transfer the local repo to PC "B". > > > > > > > 6) Transfer the changes with historie, logs, etc into the server on top > > > of the repo. > > > > > > > svnadmin dump --incremental ... > > > > svnadmin load ... > > # but this is where the whole thing goes off the rails. > > > > The load command would only work if nobody else touches the repository > (in > > a way that conflicts) in the meantime. Assuming this is unlikely. > > > > The most obvious alternative that I can think of is to use "git-svn". > > Instead of pushing changes to Subversion, push them to Git. Keep changes > in > > Git in sync with the main Subversion repository. > > > > Whenever you're ready, push changes from Git back to Subversion. > > > > Eric. > > > > > > > > > > Point 5) and 6) gives me headaches > > > > > > How can I minimize the PC "A" <=> PC "B" changes by simutanously being > > > able to checkin > > > logically sized portions including all other informations? > > > > > > Thanks a lot for any help in advance! > > > Cheers! > > > mcc > > > > > > Hi Eric, > > thank you very much for your informations and help! Very > appreciated!!! Upto but not including 5) it was already know to me... > 5) is were the magic (at least for me) begins... :) > > Would it be an option to lock the whole repo (with announcement > before) for the time of doing a 'svnadmin load"...or do you > meant with "nobody touches the repository in the meantime" the time > between 1) and end of 6)...? > Unfortunately, it means that nobody touches the repository between 1 and 6 I think the git-svn approach is likely to be the most successful strategy. Eric. > > Cheers! > mcc > > > > > >
Re: Add changes from a local svn repo to the same but older repo on a server with history
On Wed, 3 Apr 2019, Eric Johnson wrote:
> The most obvious alternative that I can think of is to use "git-svn".
> Instead of pushing changes to Subversion, push them to Git. Keep
changes in
> Git in sync with the main Subversion repository.
>
> Whenever you're ready, push changes from Git back to Subversion.
>
> Eric.
Unfortunately, it means that nobody touches the repository between 1 and 6
I think the git-svn approach is likely to be the most successful strategy.
Eric.
Since I'm also a mercurial fan I figured I'd put a plug in for:
https://bitbucket.org/durin42/hgsubversion/overview/
Mercurial might have a more friendly commandline for someone familiar with svn anyway.
I asked durin42 in irc://irc.freenode.net/mercurial just for the heck of it and
he said:
14:55 <@durin42> nemo: last I knew hgsubversion is substanially more paranoid.
14:55 < nemo> durin42: hm. is that good or bad ☺
14:55 <@durin42> nemo: (I'm sure I've previously used hgsubversion to splice
svn histories together)
14:56 <@durin42> nemo: it's good: the paranoia means it doesn't "handle" as
many repositories, but it means it's less likely to ninja-lose some data.
14:57 < nemo> durin42: I thought maybe "real" branches and such would be more
helpful, but I guess it depends... since svn branches are just folders, maybe you'd be better
off using hg cp in a situation like this anyway
14:58 <@durin42> well you could put hgsubversion in single-directory mode and
clone the parent dir of trunk
14:58 <@durin42> and it'd probably do a pretty decent job
14:58 < nemo> huh. never heard of "single directory mode"
14:59 <@durin42> typically you use hgsubversion in automatic mode, where it
sniffs for {branches,tags,trunk} and tries to do the Right Thing
14:59 <@durin42> This logic is, it seems, good enough you're blissfully unaware
of it.
Just FWIW ☺
