Branch/switch/merge question
I've read the visual guide, the subversion book, I've used subversion for years, but never really collaborated much with other people on actual software source code the way it's intended to be used, until recently. So it's only recently that I'm making use of branch/merge, and I'd like to get the advice of you more experienced svn users, about my usage pattern. In particular, I branch (and switch) from /trunk to /branches/eharvey. I then make a few commits. I switch back to /trunk, and merge from the branch. I commit to trunk. (I'm always at a loss for comment, because I'm just committing things that have already been commented. But that's a side note.) I then switch back to /branches/eharvey, and merge from /trunk. So here's my question: Even if I'm the only person who committed anything... I was fully committed on /branches/eharvey, I then became fully committed on /trunk, and when I merge back into /branches/eharvey, suddenly I'm not fully committed. My latest status (check for modifications) shows the child subfolder as modified, and when I diff it, it's the svn:mergeinfo property that's different. It shows that I merged /trunk into /branches/eharvey, even though there were no changes from trunk to merge in. So, most importantly, am I using svn branch/switch/merge in the way that it's intended to be used? Is this the normal, expected, and desired behavior, and I should just get used to it? Should my usage pattern be different somehow?
RE: Branch/switch/merge question
From: Edward Ned Harvey (svn4) [mailto:s...@nedharvey.com] Sent: Tuesday, November 26, 2013 9:13 AM To: users@subversion.apache.org Subject: Branch/switch/merge question In particular, I branch (and switch) from /trunk to /branches/eharvey. I then make a few commits. I switch back to /trunk, and merge from the branch. I commit to trunk. (I'm always at a loss for comment, because I'm just committing things that have already been commented. But that's a side note.) I then switch back to /branches/eharvey, and merge from /trunk. So here's my question: Even if I'm the only person who committed anything... I was fully committed on /branches/eharvey, I then became fully committed on /trunk, and when I merge back into /branches/eharvey, suddenly I'm not fully committed. My latest status (check for modifications) shows the child subfolder as modified, and when I diff it, it's the svn:mergeinfo property that's different. It shows that I merged /trunk into /branches/eharvey, even though there were no changes from trunk to merge in. It's a feature. The repository HEAD revision changed, i.e. someone checked in somewhere else in the repository, so svn updates the svn:mergeinfo property anyway. Personally, I wish the merge and merge tools (especially mergeinfo) used the Last Changed Revision instead. So, most importantly, am I using svn branch/switch/merge in the way that it's intended to be used? Yes. Should my usage pattern be different somehow? No, but since you're the only one working on the trunk, you don't necessarily need to branch/merge. However, if you have a continuous integration server that's constantly building and deploying new commits from trunk, then working on the feature branch and only merging when your feature branch is stable is a good thing.
Re: Can't access SVN repos from command Line: Server SSL certificate untrusted
Hello, Regarding your question, When you upgraded the server, did you also upgrade mod_dav_svn only? Or did you also upgrade httpd and/or openssl at the same time? I've asked the other team and here is their response: When you upgraded the server, did you also upgrade mod_dav_svn only? No change has occurred on mod dav svn did you also upgrade httpd and/or openssl at the same time? After svn servers migration, we have installed openssl on the web frontal machines(web server relocate all 443 request to SVN servers via apache mod proxy module).This automatically upgraded some modules of apache (ex: mod ssl). Regards
RE: Branch/switch/merge question
From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, November 26, 2013 9:30 AM No, but since you're the only one working on the trunk, you don't necessarily need to branch/merge. Thanks - I'm not the only person working on it. But sometimes I'll have something to merge back into trunk before anyone else has merged anything in. (It's a small group).
Re: Can't access SVN repos from command Line: Server SSL certificate untrusted
On 26 Nov 2013 15:39, Mehdi Hayani hayani.mehdi...@gmail.com wrote: I've asked the other team and here is their response: When you upgraded the server, did you also upgrade mod_dav_svn only? No change has occurred on mod dav svn If this means that the Subversion libraries were upgraded, but mod_dav_svn was not, that may be the reason for your problem. It's not very likely, but is worth investigating. — Brane
wc.db: corruption after move?
We are encountering working copies with nodes.presence = moved and nodes.moved_to = null As far as I have been told, this has already been fixed and backported to 1.8.5. Still, for those users which already have this corruption, is there a way to recover their working copies with standard Subversion functionality? Could a Revert work? And if it currently does not, could the Revert be more tolerant, so it could handle such cases? -Marc
Re: wc.db: corruption after move?
Marc Strapetz marc.strap...@syntevo.com writes: We are encountering working copies with nodes.presence = moved and nodes.moved_to = null What does nodes.presence = moved mean? There has never been a moved presence. Do you mean rows with nodes.moved_here=1 no corresponding rows with non-null nodes.moved_to? Or something else? As far as I have been told, this has already been fixed and backported to 1.8.5. Still, for those users which already have this corruption, is there a way to recover their working copies with standard Subversion functionality? Could a Revert work? And if it currently does not, could the Revert be more tolerant, so it could handle such cases? What operation is failing? Are you getting some error? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: Branch/switch/merge question
I've read the visual guide, the subversion book, I've used subversion for years, but never really collaborated much with other people on actual software source code the way it's intended to be used, until recently. So it's only recently that I'm making use of branch/merge, and I'd like to get the advice of you more experienced svn users, about my usage pattern. In particular, I branch (and switch) from /trunk to /branches/eharvey. I then make a few commits. I switch back to /trunk, and merge from the branch. I commit to trunk. (I'm always at a loss for comment, because I'm just committing things that have already been commented. But that's a side note.) I then switch back to /branches/eharvey, and merge from /trunk. So here's my question: Even if I'm the only person who committed anything... I was fully committed on /branches/eharvey, I then became fully committed on /trunk, and when I merge back into /branches/eharvey, suddenly I'm not fully committed. My latest status (check for modifications) shows the child subfolder as modified, and when I diff it, it's the svn:mergeinfo property that's different. It shows that I merged /trunk into /branches/eharvey, even though there were no changes from trunk to merge in. Are you using svn 1.8? If not, are you doing reintegration merge when merging your branch back in to the trunk? So, most importantly, am I using svn branch/switch/merge in the way that it's intended to be used? Is this the normal, expected, and desired behavior, and I should just get used to it? Should my usage pattern be different somehow? Generally, there isn't a reason to branch as a matter of course. It's not wrong per say... but I'd rather see all the work just done in trunk. Branches would be used for larger features that multiple people might collaborate on, or take longer than a day or so. Although, having each developer work only on a branch does facilitate code reviews. You do your work on a branch, someone reviews it, once ok'ed it gets merged to branch. Also, I suggest people avoid using switch. It is too easy to forget which svn path you are currently pointing to and commit something to the wrong path. Also, svn switch doesn't handle non-versioned stuff as well as say GIT does. I'd much rather see our devs check out trunk and branch to separate local working copies. BOb
Re: wc.db: corruption after move?
On 26.11.2013 18:08, Philip Martin wrote: Marc Strapetz marc.strap...@syntevo.com writes: We are encountering working copies with nodes.presence = moved and nodes.moved_to = null What does nodes.presence = moved mean? There has never been a moved presence. Do you mean rows with nodes.moved_here=1 no corresponding rows with non-null nodes.moved_to? Or something else? As far as I have been told, this has already been fixed and backported to 1.8.5. Still, for those users which already have this corruption, is there a way to recover their working copies with standard Subversion functionality? Could a Revert work? And if it currently does not, could the Revert be more tolerant, so it could handle such cases? What operation is failing? Are you getting some error? Marc is looking at some code that converts wc.db info to some internal structure ... Marc, can you please explain how the wc.db itself looks like? Hint: we don't support SmartSVN or SVNKit here. :) -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: wc.db: corruption after move?
On 26.11.2013 18:27, Branko Čibej wrote: On 26.11.2013 18:08, Philip Martin wrote: Marc Strapetz marc.strap...@syntevo.com writes: We are encountering working copies with nodes.presence = moved and nodes.moved_to = null What does nodes.presence = moved mean? There has never been a moved presence. Do you mean rows with nodes.moved_here=1 no corresponding rows with non-null nodes.moved_to? Or something else? As far as I have been told, this has already been fixed and backported to 1.8.5. Still, for those users which already have this corruption, is there a way to recover their working copies with standard Subversion functionality? Could a Revert work? And if it currently does not, could the Revert be more tolerant, so it could handle such cases? What operation is failing? Are you getting some error? Marc is looking at some code that converts wc.db info to some internal structure ... Marc, can you please explain how the wc.db itself looks like? Hint: we don't support SmartSVN or SVNKit here. :) FWIW, I've been promised a reproduction script using the command-line. Hope it'll be ready soon. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: wc.db: corruption after move?
On 26.11.2013 18:27, Branko Čibej wrote: On 26.11.2013 18:08, Philip Martin wrote: Marc Strapetz marc.strap...@syntevo.com writes: We are encountering working copies with nodes.presence = moved and nodes.moved_to = null What does nodes.presence = moved mean? There has never been a moved presence. Sorry, actually in the underlying wc.db, it should be: presence = normal and op_depth 0 and moved_here 0 Do you mean rows with nodes.moved_here=1 no corresponding rows with non-null nodes.moved_to? Exactly, that seems to be the case. Or something else? As far as I have been told, this has already been fixed and backported to 1.8.5. Still, for those users which already have this corruption, is there a way to recover their working copies with standard Subversion functionality? Could a Revert work? And if it currently does not, could the Revert be more tolerant, so it could handle such cases? What operation is failing? Are you getting some error? I can't tell whether an operation fails, because an assertion when reading the wc.db is hit before. I'd expect some operations (in the GUI) to fail later, because we are assuming at various places that a moved file must have a move-source. Is this assumption correct? Marc is looking at some code that converts wc.db info to some internal structure ... Marc, can you please explain how the wc.db itself looks like? Hint: we don't support SmartSVN or SVNKit here. :) Unfortunately I haven't seen such a wc.db until now, but when tracing back the conversions we do, the resulting problematic wc.db *should* look like as described above. -- Best regards, Marc Strapetz = syntevo GmbH http://www.syntevo.com
'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_subr\dirent_uri.c' line 1571: assertion failed (! svn_path_is_url(relative))
--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_subr\dirent_uri.c' line 1571: assertion failed (! svn_path_is_url(relative)) --- OK I was trying to checkout projects from my svn repostitory to my working directory. I created the working directory by creating the folder, then using TortoiseSVN to create the subfolders. When I try to check out to trunk I get the above error message. I am using subversion version 1.8.3 and Tortoise SVN 1.8.2 ~ Regards ~ Rachael PeopleSoft Support Team National Security Technologies, LLC Contractor to the United States Department of Energy (702) 295-4679
Re: wc.db: corruption after move?
Marc Strapetz marc.strap...@syntevo.com writes: As far as I have been told, this has already been fixed and backported to 1.8.5. Still, for those users which already have this corruption, is there a way to recover their working copies with standard Subversion functionality? Could a Revert work? And if it currently does not, could the Revert be more tolerant, so it could handle such cases? What operation is failing? Are you getting some error? I can't tell whether an operation fails, because an assertion when reading the wc.db is hit before. I'd expect some operations (in the GUI) to fail later, because we are assuming at various places that a moved file must have a move-source. Is this assumption correct? Is that Subversion that is asserting? It would help if you showed the exact error or assertion. If moved_to is missing Subversion usually falls back to copy and delete: $ svnadmin create repo $ svn import -mm repo/format file://`pwd`/repo/A/f $ svn co file://`pwd`/repo wc $ svn wc/A wc/B $ svn mv wc/B/f wc/B/g $ svn st wc D wc/A moved to wc/B D wc/A/f A +wc/B moved from wc/A D +wc/B/f moved to wc/B/g A +wc/B/g moved from wc/B/f $ sqlite3 wc/.svn/wc.db update nodes set moved_to = null $ svn st wc D wc/A D wc/A/f A +wc/B D +wc/B/f A +wc/B/g -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: 'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_subr\dirent_uri.c' line 1571: assertion failed (! svn_path_is_url(relative))
This error is caused by passing an url to an API where a local path was expected. Whether this is a user error that should have been properly reported by TortoiseSVN or a bug in TortoiseSVN is impossible to tell for us without you showing how you invoked the operation. Bert Sent from Windows Mail From: Beatty, Rachael Sent: Tuesday, November 26, 2013 9:17 PM To: users@subversion.apache.org --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_subr\dirent_uri.c' line 1571: assertion failed (! svn_path_is_url(relative)) --- OK I was trying to checkout projects from my svn repostitory to my working directory. I created the working directory by creating the folder, then using TortoiseSVN to create the subfolders. When I try to check out to trunk I get the above error message. I am using subversion version 1.8.3 and Tortoise SVN 1.8.2 ~ Regards ~ Rachael PeopleSoft Support Team National Security Technologies, LLC Contractor to the United States Department of Energy (702) 295-4679
Re: Experiencing issue where CPU is pinned at 100% - more info
Had this been filed as a bug? From: Administrator da...@gamehouse.commailto:da...@gamehouse.com Date: Friday, November 22, 2013 at 2:29 PM To: users@subversion.apache.orgmailto:users@subversion.apache.org users@subversion.apache.orgmailto:users@subversion.apache.org Subject: Experiencing issue where CPU is pinned at 100% - more info Config: OS: Windows 2012 Server 64bit 1TB SSD 8GiB RAM Software version4.0.2-3732.117 Subversion version 1.8.3-3732.117 Running since 11/21/2013 14:06:28 PST Repo health Total repositories: 2 - Go to the Repositories tab to create or discover repositories. Throughput on primary interface 0.0 B/s IN (over about 5 minutes); 0.0 B/s OUT (over about 5 minutes) Disk Usage as of 11/22/2013 11:10:31 PST Used space on root volume 565.43 GB Used space by repositories 138.65 GB Free space on repository volume 328.81 GB Authenticating with LDAP AD ~45 active user We migrated Two days ago. I dumped the repo to a new physical machine and imported it through the Web Interface. Every day, at some point, the repository becomes inaccessible. I RDC to the box and Apache is using 100% of the CPU. The entire machine is performing ridiculously slow. A restart of the Service restores CPU to normal and everyone carries on until the next occurrence. I parsed the error log for yesterday counting occurrences of all AH errors: occurrences: DEBUG Code 545112 AH01626: 206385 AH01691: 206377 AH01697: 139630 AH01384: 24 AH00361: 4 AH01316: 2 AH01320: 2 AH01318: 2 AH00408: 2 AH00403: 2 AH00348: 2 AH00334: 1 AH01284: 1 AH00456: 1 AH00455: 1 AH00453: 1 AH00431: 1 AH00422: 1 AH00418: 1 AH00411: 1 AH00407: 1 AH00402: 1 AH00391: 1 AH00359: 1 AH00357: 1 AH00354: 1 AH00352: 1 AH00096: 1 AH00094: I looked at the error log unto the point of the restart. I could not see anything obvious. I also look in the event viewer and see nothing. Dave Kelsey
RE: Can't access SVN repos from command Line: Server SSL certificate untrusted
From: Branko Čibej [mailto:br...@wandisco.com] Sent: Tuesday, November 26, 2013 11:17 AM On 26 Nov 2013 15:39, Mehdi Hayani hayani.mehdi...@gmail.com wrote: I've asked the other team and here is their response: When you upgraded the server, did you also upgrade mod_dav_svn only? No change has occurred on mod dav svn If this means that the Subversion libraries were upgraded, but mod_dav_svn was not, that may be the reason for your problem. It's not very likely, but is worth investigating. Sorry I just joined this discussion, and I don't have the history, but the subject caught my attention, and I happen to know something (usually a lot) about ssl certificates and so forth... What are the important details and/or original post that I'm missing? I'm only responding to the generic can't access SVN repos, certificate untrusted. I'm assuming you're using apache httpd, serving https, and I've certainly seen many situations where some slight variation in the way you install your server cert causes some clients (such as Chrome) to show the cert looking good... while other clients complain about the cert. (I've learned nothing, if not, that you need to test every version of every client on every platform that you care to support.) I'm making assumptions about your problem, and motivated to say: The most common reason for a cert to be accepted by one client and rejected by another client, is the ordering of the certificate chain. If you needed to concatenate some certs into cert file, the correct ordering is your local server cert, followed by intermediate, followed by root CA. But maybe I'm cluelessly talking about something unrelated to your actual problem. Sorry if so...
Re: Experiencing issue where CPU is pinned at 100% - more info
On 11/22/13 2:29 PM, Dave Kelsey wrote: Software version 4.0.2-3732.117 What is this a software version of? You didn't mention what version of Apache httpd you're using. Though I'm guessing 2.4.x given the log message codes you gave below. It's possible this is actually a httpd issue and not a svn issue. I parsed the error log for yesterday counting occurrences of all AH errors: occurrences: DEBUG Code 545112 AH01626: Unimportant, just logging the result of the authorization hook in mod_authz_core.c 206385 AH01691: Client didn't send a password log message (mod_authnz_ldap.c). Probably normal since client doesn't authenticate until it's asked for authentication. 206377 AH01697: access granted in mod_authnz_ldap.c 139630 AH01384: mod_deflate.c telling how much it compressed things. 24 AH00361: From mpm/winnt/child.c (no idea what this means) /* Shutdown the worker threads * Post worker threads blocked on the ThreadDispatch IOCompletion port Could be normal I'm not super knowledgeable about the winnt mpm. 4 AH01316: Some sort of message LDAP caching modules/ldap/util_ldap.c 2 AH01320: LDAP SSL support unavailable modules/ldap/until_ldap.c (this looks suspicious to me) 2 AH01318: logging the LDAP SDK used. modules/ldap/util_ldap.c 2 AH00408: Looks like a normal operation of winnt mpm with duplicating a socket. mpm/winnt/mpm_winnt.c 2 AH00403: Looks like a normal operation of winnt mpm, waiting for data on a socket. mpm/winnt/mpm_winnt.c 2 AH00348: Child: Accept thread exiting. Could be just part of a normal shutdown. mpm/winnt/child.c 2 AH00334: Child: Listening on an address with a filter. Normal operation mpm/winnt/child.c 1 AH01284: ldap timed out modules/ldap/util_ldap.c 1 AH00456: logging date and time the server was built. mpm/winnt/mpm_winnt.c 1 AH00455: startup finished (resuming normal operation message) mpm/winnt/mpm_winnt.c 1 AH00453: Child process startup, normal operation mpm/winnt/mpm_winnt.c 1 AH00431: Parent forcing child to terminate, part of shutdown. mpm/winnt/mpm_winnt.c 1 AH00422: shutdown signal received, part of shutdown mpm/winnt/mpm_winnt.c 1 AH00418: Created child process, normal operation mpm/winnt/mpm_winnt.c 1 AH00411: More normal operation of the socket duplication mpm/winnt/mpm_winnt.c 1 AH00407: Child side of the previous message, child got the duplicated sockets. mpm/winnt/mpm_winnt.c 1 AH00402: Sent scoreboard handle to child, normal operation mpm/winnt/mpm_winnt.c 1 AH00391: Child got the soreboard from the previous message mpm/winnt/mpm_winnt.c 1 AH00359: Child released start mutex, normal operation mpm/winnt/mpm_winnt.c 1 AH00357: Child got an exit signal, part of shutdown mpm/winnt/child.c 1 AH00354: Creation of worker threads in child, normal operation mpm/winnt/child.c 1 AH00352: Child got the start mutix, normal operation mpm/winnt/child.c 1 AH00096: removed pid file, part of shutdown log.c 1 AH00094: logging of startup command, normal operation log.c I looked at the error log unto the point of the restart. I could not see anything obvious. I also look in the event viewer and see nothing. Based on the above it looks to me like you're having some sort of issue with your LDAP connectivity. But it's almost impossible to diagnose from the information provided. I suggest attaching a debugger and seeing what it's doing when it's spinning at 100% CPU. WinDbg and the Logexts.dll will let you log system calls: http://msdn.microsoft.com/en-us/library/windows/hardware/ff560170%28v=vs.85%29.aspx On 11/26/13 3:35 PM, Dave Kelsey wrote: Had this been filed as a bug? No and at this point I don't see a clear cause. May not even be a Subversion problem. So I wouldn't open an issue yet.
RE: Branch/switch/merge question
From: Bob Archer [mailto:bob.arc...@amsi.com] Are you using svn 1.8? Oh - uhm... I'm using TortoiseSVN, 1.8.2, which is built against Subversion 1.8.3. If not, are you doing reintegration merge when merging your branch back in to the trunk? I'm not familiar with those words. Maybe next time I merge, I'll look for a checkbox or something that says reintegration. ? If I see it, I don't know what it means... I guess I'll google for svn reintegration merge. Generally, there isn't a reason to branch as a matter of course. It's not wrong per say... but I'd rather see all the work just done in trunk. Branches would be used for larger features that multiple people might collaborate on, or take longer than a day or so. The reason we decided to start branching was... As long as we were all (all 3 of us) working on trunk, none of us would commit anything that still caused a compile error, or hadn't been at least tested to be launchable. Nobody wanted to be responsible for blocking the others from actually developing. So we decided to all start branching and doing more frequent commits. The other 2 guys are git fanatics, but I'm the IT person, and I don't want to deal with git for now. Effort into migrating toward git would be effort mal-spent in a tiny startup. If all we want to do is branch merge, I know svn can handle that. I just want to be sure we're not being idiots in some way cuz none of us has ever done it before (with svn). Also, I suggest people avoid using switch. It is too easy to forget which svn path you are currently pointing to and commit something to the wrong path. Also, svn switch doesn't handle non-versioned stuff as well as say GIT does. I'd much rather see our devs check out trunk and branch to separate local working copies. I think you're talking about git stash. Right? And I think you're saying... At first, I was doing a sparse checkout. I non-recursively checked out /, and then I made /trunk fully recursive, and then I went one level deeper into /branches, and then I made /branches/eharvey fully recursive... And then I discovered how natural it was to switch merge, so I got rid of my whole working copy, and re-checked out recursively (non-sparse) /trunk. But it sounds like you suggest going back to the non-recursive checkout of /, with recursive /trunk, and recursive /branches/eharvey. Just to keep the branch trunk logically separate from each other and eliminate any user error regarding Which what, oh, where am I? I forget... You might be right... and if I say so to the other guys, they might use this to bludgeon me into git. ;-)
Re: Apache Subversion 1.8.5 released
I've gone ahead and updated, and casually tested, my published RHEL 6 compatible RPM building tools with a new 1.8.5 tag at: https://github.com/nkadel/subversion-1.8.x-srpm/tree/1.8.5-0.1 For those who work in RHEL 6 or CentOS 6 or Scientific Linux 6, it works quite well with the libserf from EPEL. Nico Kadel-Garcia nka...@gmail.com
Re: Experiencing issue where CPU is pinned at 100% - more info
Ben, Thanks for responding. I'll follow up with the debug route. I used a couple of tools to query our AD and had no trouble using the settings from the leap config. We only have 96 users. Thanks for your help. Dave Sent from my iPhone On Nov 26, 2013, at 5:52 PM, Ben Reser b...@reser.org wrote: On 11/22/13 2:29 PM, Dave Kelsey wrote: Software version4.0.2-3732.117 What is this a software version of? You didn't mention what version of Apache httpd you're using. Though I'm guessing 2.4.x given the log message codes you gave below. It's possible this is actually a httpd issue and not a svn issue. I parsed the error log for yesterday counting occurrences of all AH errors: occurrences: DEBUG Code 545112 AH01626: Unimportant, just logging the result of the authorization hook in mod_authz_core.c 206385 AH01691: Client didn't send a password log message (mod_authnz_ldap.c). Probably normal since client doesn't authenticate until it's asked for authentication. 206377 AH01697: access granted in mod_authnz_ldap.c 139630 AH01384: mod_deflate.c telling how much it compressed things. 24 AH00361: From mpm/winnt/child.c (no idea what this means) /* Shutdown the worker threads * Post worker threads blocked on the ThreadDispatch IOCompletion port Could be normal I'm not super knowledgeable about the winnt mpm. 4 AH01316: Some sort of message LDAP caching modules/ldap/util_ldap.c 2 AH01320: LDAP SSL support unavailable modules/ldap/until_ldap.c (this looks suspicious to me) 2 AH01318: logging the LDAP SDK used. modules/ldap/util_ldap.c 2 AH00408: Looks like a normal operation of winnt mpm with duplicating a socket. mpm/winnt/mpm_winnt.c 2 AH00403: Looks like a normal operation of winnt mpm, waiting for data on a socket. mpm/winnt/mpm_winnt.c 2 AH00348: Child: Accept thread exiting. Could be just part of a normal shutdown. mpm/winnt/child.c 2 AH00334: Child: Listening on an address with a filter. Normal operation mpm/winnt/child.c 1 AH01284: ldap timed out modules/ldap/util_ldap.c 1 AH00456: logging date and time the server was built. mpm/winnt/mpm_winnt.c 1 AH00455: startup finished (resuming normal operation message) mpm/winnt/mpm_winnt.c 1 AH00453: Child process startup, normal operation mpm/winnt/mpm_winnt.c 1 AH00431: Parent forcing child to terminate, part of shutdown. mpm/winnt/mpm_winnt.c 1 AH00422: shutdown signal received, part of shutdown mpm/winnt/mpm_winnt.c 1 AH00418: Created child process, normal operation mpm/winnt/mpm_winnt.c 1 AH00411: More normal operation of the socket duplication mpm/winnt/mpm_winnt.c 1 AH00407: Child side of the previous message, child got the duplicated sockets. mpm/winnt/mpm_winnt.c 1 AH00402: Sent scoreboard handle to child, normal operation mpm/winnt/mpm_winnt.c 1 AH00391: Child got the soreboard from the previous message mpm/winnt/mpm_winnt.c 1 AH00359: Child released start mutex, normal operation mpm/winnt/mpm_winnt.c 1 AH00357: Child got an exit signal, part of shutdown mpm/winnt/child.c 1 AH00354: Creation of worker threads in child, normal operation mpm/winnt/child.c 1 AH00352: Child got the start mutix, normal operation mpm/winnt/child.c 1 AH00096: removed pid file, part of shutdown log.c 1 AH00094: logging of startup command, normal operation log.c I looked at the error log unto the point of the restart. I could not see anything obvious. I also look in the event viewer and see nothing. Based on the above it looks to me like you're having some sort of issue with your LDAP connectivity. But it's almost impossible to diagnose from the information provided. I suggest attaching a debugger and seeing what it's doing when it's spinning at 100% CPU. WinDbg and the Logexts.dll will let you log system calls: http://msdn.microsoft.com/en-us/library/windows/hardware/ff560170%28v=vs.85%29.aspx On 11/26/13 3:35 PM, Dave Kelsey wrote: Had this been filed as a bug? No and at this point I don't see a clear cause. May not even be a Subversion problem. So I wouldn't open an issue yet.
Would you please send information as to what I'm s...
Would you please send information as to what I'm subscribed to
Hardware requirements for windows subversion
Hello, I am looking to use subversion for .Net applications. What type of hardware do I need? What version of windows server, RAM, hard disk space do I need? Thanks. -- View this message in context: http://subversion.1072662.n5.nabble.com/Hardware-requirements-for-windows-subversion-tp185979.html Sent from the Subversion Users mailing list archive at Nabble.com.
RE: Hardware requirements for windows subversion
-Original Message- From: Ram [mailto:house4rent...@yahoo.com] Sent: 27 November 2013 00:33 Hello, I am looking to use subversion for .Net applications. What type of hardware do I need? What version of windows server, RAM, hard disk space do I need? Short answer: it depends. Longer answer: it would help if you gave some indication of the sort of workload you expect the server to handle. I have a relatively simple setup running windows server on a virtual machine with 512MB RAM provisioned and enough disk space. That serves about 15 European users on an internal network, all using https. The server also runs Trac (trac.edgewall.org) and a few other minor scheduled tasks. I originally setup a standard desktop machine with no problems. If you want to serve thousands of users spread across the globe with uptime and access requirements then you will probably need a bit more. So: it depends! ~ mark c
