Memory leak in mod_sav_svn?
Hi, we're running a SVN repo (~6GB) on 1.7.3. Checking out the entire repo in one "svn co" (both 1.6 and 1.7) session is almost impossible. The httpd process starts consuming up to 4GB and then dies, killing the svn client process with: svn: REPORT of '/svn/prod/!svn/vcc/default': Could not read chunk size: connection was closed by server Even more interesting, apache does not log anything in its error log. To me, this looks like a memory leak. Is there any way to debug this further? Please CC me, thanks. -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
403 forbidden when Commiting
Hi.. I have a folder called "a.b.c.d.svn.client" but whe i commiting this folder to my svn it get 403 Forbidden ERROR , but when i rename it to "a.b.c.d.repo.client " commit works perfectly. is there any reason for that Thank You Parakrama
RE: 403 forbidden when Commiting
> -Original Message- > From: dhanushka ranasinghe [mailto:parakrama1...@gmail.com] > Sent: 05 March 2012 16:29 > To: users@subversion.apache.org > Subject: 403 forbidden when Commiting > > Hi.. > > I have a folder called "a.b.c.d.svn.client" but whe i > commiting this folder to my svn it get 403 Forbidden ERROR , > but when i rename it to "a.b.c.d.repo.client " commit works > perfectly. > > is there any reason for that > > > Thank You > Parakrama As a first guess, do you have any pre-commit hooks that parse paths? As a second guess, do you have any apache rules that forbid access to any path containing `.svn` (often used to prevent browsing of the svn "pristene" directories)? Actually, thinking about it I would check the second first! ~ mark c
Getting initial sync from multiple users to single repository
I can't seem to find this particular problem in the archives, but that may be my ignorance of the terminology. I want to start using svn for a project which currently has four user machines, each with their own copy of the codebase, kept in sync by manual scp to and from one of the machines which has been acting as master. I have created an svn repository on another host, and added all the files from one user machine to it (some weeks ago), so everything was present but unversioned. Since then, a few of those files have been manually edited on that user machine, without checking them out, so the first question is, how do I push those few files to the server so that the repository contains the updated copies? If I use add or checkin, it fails on the first changed file, saying it already exists: Adding 0007.pdf svn: Commit failed (details follow): svn: File '/svn/interfaces/0007.pdf' already exists which is perfectly understandably as it was never checked out but edited locally. Is there a command that will force the server to accept a file that has been modified locally, or should I just wipe the whole repo and start afresh? Assuming I can solve that one, I then need to add the other user machines' files. All the major components of the project will already be identical, so they can be checked out from the repository, but many smaller files, mostly reference and historical material, will be different on each user machine, but the most recent one is what I need (all the machines run ntp, so I am assuming I can trust the timestamps). None of these are critical, but it would be nice to have them added and checked in only if their timestamp is more recent than any copy already in the repository. Can this be done using svn, or do I need to do it manually (well, maybe with rsync) and then checkin the result? ///Peter
Re: Getting initial sync from multiple users to single repository
On Mon, Mar 5, 2012 at 1:29 PM, Peter Flynn wrote: > > I have created an svn repository on another host, and added all the files > from one user machine to it (some weeks ago), so everything was present but > unversioned. Since then, a few of those files have been manually edited on > that user machine, without checking them out, so the first question is, how > do I push those few files to the server so that the repository contains the > updated copies? If I use add or checkin, it fails on the first changed file, > saying it already exists: Check out a working copy, replace the files in it with the corresponding modified files and commit them. Better yet, make each of the users making the changes do this step themselves and add meaningful log messages, and then they can keep on working in their working copies and remove the original unversioned directory. -- Les Mikesell lesmikes...@gmail.com
Re: Getting initial sync from multiple users to single repository
Guten Tag Peter Flynn, am Montag, 5. März 2012 um 20:29 schrieben Sie: > Is there a command that will force the server to accept a file > that has been modified locally, or should I just wipe the whole repo and > start afresh? As already said, checkout your current repo to a new directory, copy the files you want to update over the working copy and commit the changes. > Assuming I can solve that one, I then need to add the other user > machines' files. All the major components of the project will already be > identical, so they can be checked out from the repository, but many > smaller files, mostly reference and historical material, will be > different on each user machine, but the most recent one is what I need > (all the machines run ntp, so I am assuming I can trust the timestamps). > None of these are critical, but it would be nice to have them added and > checked in only if their timestamp is more recent than any copy already > in the repository. Can this be done using svn, or do I need to do it > manually (well, maybe with rsync) and then checkin the result? Do as the first time, checkout the repo, with the already updated contents now, and copy the local files over the working copy. The easiest is to copy all files regardless of timestamps or else and let svn using svn status or svn commit see itself what was changed and commit the changes again as needed. Consider that on this simple setup with all working copies presenting the same directory structure and files, you can't have different file contents of special files on each of your machines/users because each user's commit would change the contents of the committed file for all other users resulting in changes or even conflicts for the other users, depending on the nature of the changes made. You may need to separate user specific files in different directories, but this would heavily depend on the nature of the file changes you are talking about. 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 Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Getting initial sync from multiple users to single repository
May be useful here: 'svn checkout --force' will take an existing tree and make it into a working copy. (Preexisting files will show as local mods when the command finishes.) Les Mikesell wrote on Mon, Mar 05, 2012 at 14:06:55 -0600: > On Mon, Mar 5, 2012 at 1:29 PM, Peter Flynn wrote: > > > > I have created an svn repository on another host, and added all the files > > from one user machine to it (some weeks ago), so everything was present but > > unversioned. Since then, a few of those files have been manually edited on > > that user machine, without checking them out, so the first question is, how > > do I push those few files to the server so that the repository contains the > > updated copies? If I use add or checkin, it fails on the first changed file, > > saying it already exists: > > Check out a working copy, replace the files in it with the > corresponding modified files and commit them. Better yet, make each > of the users making the changes do this step themselves and add > meaningful log messages, and then they can keep on working in their > working copies and remove the original unversioned directory. > > -- > Les Mikesell > lesmikes...@gmail.com
Re: Getting initial sync from multiple users to single repository
On 05/03/12 19:29, Peter Flynn wrote: I want to start using svn for a project[...] Thank you all very much for the advice. That should do the job. ///Peter
Updated Pre-Commit "Kitchen Sink" Trigger
I've recently made several major updates to my "Kitchen Sink" pre-commit hook that I know quite a few of you have used. The whole hook has been completely rewritten from scratch in order to make it easier to maintain. There are several changes that I've incorporated based upon a few requests: * The biggest change is that the control.ini file can now be stored right in the repository instead of the hook directory of the repository. This means you no longer have to sign onto the Subversion repository server in order to maintain the file. Simply check it out, and make your changes. This is a big relief for those who don't have direct access to your repository servers. As a bonus (and another request), you can now track the changes to the control file. Who made them, when, and why. I'm currently working on a parser that will verify the control file to prevent you from checking in a bad one. * The hook can now use groups from your Windows Active Directory or your LDAP server instead of manually defining the groups in the control file. This means less maintenance. Plus, it is no longer your headache when a developer leaves one group and goes to another. That's now your System Administrator's job. * Along with the standard three permissions "read-only", "read-write", and "add-only" are "no-delete" and "no-add". The hook is now available via GitHub at https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook. Yes, it's a bit ironic, but it's easier to get to than my old Public Dropbox. Please download the latest copy and let me know if there are any more suggestions. -- David Weintraub qazw...@gmail.com
svn: Attempted to get textual contents of a *non*-file node
Hi all, I ran into the following error message with Subversion: svn: Attempted to get textual contents of a *non*-file node The issue, as pointed out by email thread [1], is that the directory being merged contains a file with the same name as the directory. I.e., there is /trunk/foo directory containing /trunk/foo/foo file. However, even if I tried the suggestion from Ben Collins-Sussman, it didn't help: 'svn merge' still complained with the same error message. Reproduction script attached. Is there a way such projects can use 'svn merge' command? I tried with Subversion trunk and, although the error message is different ("svn: E160017: '/trunk/foo' is not a file"), the result is still the same. While it is a better message than the one in 1.6, it still does not explain why Subversion expects /trunk/foo to be a file for the following commands: svn merge -c 4 ^/trunk/foo svn merge -c 4 ^/trunk/foo . svn merge ^/trunk/foo@3 ^/trunk/foo@4 . svn merge -r 3:4 ^/trunk/foo . As another side note, Subversion leaves behind a zero-sized temporary file created for the merge. Regards, Alexey. [1] http://markmail.org/message/qqh3r6d4tcdyjnz2#query: +page:1+mid:vcjektlfn37mxyld+state:results x.sh Description: application/shellscript
Re: svn: Attempted to get textual contents of a *non*-file node
Alexey Neyman wrote on Mon, Mar 05, 2012 at 16:14:24 -0800: > Hi all, > > I ran into the following error message with Subversion: > > svn: Attempted to get textual contents of a *non*-file node > > The issue, as pointed out by email thread [1], is that the directory being > merged contains a file with the same name as the directory. I.e., there is > /trunk/foo directory containing /trunk/foo/foo file. > > However, even if I tried the suggestion from Ben Collins-Sussman, it didn't > help: 'svn merge' still complained with the same error message. Reproduction > script attached. Is there a way such projects can use 'svn merge' command? > > I tried with Subversion trunk and, although the error message is different > ("svn: E160017: '/trunk/foo' is not a file"), the result is still the same. > While it is a better message than the one in 1.6, it still does not explain > why Subversion expects /trunk/foo to be a file for the following commands: > > svn merge -c 4 ^/trunk/foo > svn merge -c 4 ^/trunk/foo . > svn merge ^/trunk/foo@3 ^/trunk/foo@4 . > svn merge -r 3:4 ^/trunk/foo . > Yeah, I just tried with trunk, couldn't get the merge to work, with those commands (some of which are made equivalent by the argument parser) or with . Looks like a bug to me, assuming it works when the dir and the file are not both named the same thing. > As another side note, Subversion leaves behind a zero-sized temporary file > created for the merge. > And this one too. (the file is in the wc root) > Regards, > Alexey. > > [1] http://markmail.org/message/qqh3r6d4tcdyjnz2#query: > +page:1+mid:vcjektlfn37mxyld+state:results Could you file an issue? Perhaps send a patch adding a regression test for this (in Python)? (See subversion/tests/cmdline/README) Thanks -- Daniel