svndumpfilter2 or svndumpfilter3 on Windows
Hi, Has anybody had any success using svndumpfilter2 or svndumpfilter3 on Windows. I need to create a dump along with files copied from outside the area on interest. svndumpfilter2 fails to get any file contents and svndumpfilter3 seems to create an invalid dump. Any help on this would be great or an alternative solution. Thanks Guys Chris *bypass*
Re: commit not validated
Hi list, Should I understand that there's no "standard" solution to this problem, or nobody can answer this issue ? Or did I do something wrong in the previous mail ? I think this can't be resolved with obvious basic configuration. Thanks in advance, Le 07/03/2011 17:28, Bastien Semene a écrit : Hi list, I'd like to know if it is possible to commit code not updatable (not validated) until a flag is set/unset ? Here is our problem : We have projects with source code and datas, and a buildmachine build the executable(s). At time 0 the code is commited, the buildmachine starts building. At time + X (X >= 0) new data model is commited. At time + Y (Y > X) compilation is successfull and the new data can be read/write by the executable. During time Y-X, the project is broken as the old executable can't read new datas. I wish to let people - data or source code providers - commit while they cannot automatically update these revisions (they can force it, the buildmachine for example needs new source code if something fails during the previous build). Something like "not validated" commits can be an answser, but I didn't see anything allowing this on SVN. I've thought to some other durty solutions, but I'd like to be sure there's no clean way before starting anything. -- Bastien Semene Administrateur Réseau& Système Cyanide Studio - FRANCE
Re: commit not validated
Bastien Semene wrote: Hi list, Should I understand that there's no "standard" solution to this problem, or nobody can answer this issue ? Or did I do something wrong in the previous mail ? I think this can't be resolved with obvious basic configuration. That's what branches are for. Work in branch where you can break anything you want then when it's ready, merge it to the trunk.
Re: 'Could not get next bucket brigade' error
03/06/2011 06:22 PM, Andy Levy writes: > On Sat, Mar 5, 2011 at 22:34, Konstantin Boyandin wrote: >> Hello, >> >> Setup: there's a server where Subversion repository is located (working >> via Apache backend), OS CentOS 5.5, Subversion installed as RPM >> subversion-1.4.2-4.el5_3.1 >> >> Client: Fedora 14, Subversion installed from RPM >> subversion-1.6.15-1.fc14.x86_64 >> >> Problem: until yesterday, everything was fine. Yesterday and from now >> on, when I try to commit changes, I see messages like this on client side: >> >> $ svn commit -m "Test update" >> Sending05/0/sh05p2.lyx >> Transmitting file data .svn: Commit failed (details follow): >> svn: Server sent unexpected return value (500 Internal Server Error) in >> response to PUT request for >> '/books/!svn/wrk/03fb3e1c-cd66-4799-ad3d-3d68c5787936/private/Shamteran/05/0/sh05p2.lyx' >> >> On the server side, the following appears in Apache logs: >> [error] [client xx.xx.xx.xx] Could not get next bucket brigade [500, #0] >> >> I have rebuilt the repository from scratch, loaded the yesterday's dump >> (made prior to update that started to cause error), result is the same. >> >> I would appreciate advice on >> - how to find the reason for the error >> - how to fix it without creating a new repository from scratch and >> losing all the history of changes so far >> >> Running fsfsverify.py against the several latest rev file resulted in >> nothing. > > 2 points: > 1) SVN 1.4.x is no longer supported. CentOS/RHEL do follow the tradition of keeping very old versions in their repositories. Unless absolutely unavoidable, I prefer not to compile the software pieces manually, otherwise I will end building almost everything from sources, with all the consequences. > 2) This is an Apache error, not Subversion. It can happen on servers > that don't even have Subversion installed. This may be relevant to > your installation: https://bugzilla.redhat.com/show_bug.cgi?id=572932 Thanks, the whole issue was malfunctioning hypervisor + faulty router device at the hoster's. As soon as they fixed the mentioned problems, the eerie 'buckert brigade' error was gone. Sincerely, Konstantin
