Takács András writes:
> / # svn mkdir file:///var/svn/testrepo/xxx -m "aaa"
> fs_fs: [LINE 2082] calling svn_fs_fs__read_noderev
> fs_fs: [LINE 2140] calling read_rep_offsets '0 0 4 4
> 2d2977d1c96f487abe4a1e202dd03b4e'
> read_rep_offsets: [LINE 1947] '0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e'
>
Takács András writes:
> 2010/12/3 Philip Martin :
>> Takács András writes:
>>
>>> / # svn mkdir file:///var/svn/testrepo/xxx -m "aaa"
>>> fs_fs: [LINE 2082] calling svn_fs_fs__read_noderev
>>> fs_fs: [LINE 2140] calling read_rep_o
Takács András writes:
> One more interesting addition:
>
> The representation_string function is called from svn_fs_fs__write_noderev.
> Here at the nodrerev->data_rep section I preinted out the revision,
> offset, size, enpanded_size fields from the noderev->data_rep
> structure:
>
> rev 0
> off
Philip Martin writes:
> Takács András writes:
>
>> The next debug step is in the representation_string function. Before
>> calling the apr_psprintf function, I printed out again the fields:
>>
>> rs rev 0
>> rs offs 4618628953320456192
>
> in hex: 4018
Takács András writes:
> I checked my toolchain. It's using 32 bit file offsets.
> I tried an other toolchain (ct-ng + eglibc). Same result. :(
>
> 2010/12/3 Philip Martin :
>> Takács András writes:
>>
>>> Here at the nodrerev->data_rep section I pr
Takács András writes:
>> Here you are printing 64-bits, so some part of your system thinks that
>> apr_off_t is 64-bits. How are apr_off_t and APR_HAS_LARGE_FILES defined
>> in apr.h?
>
> #define APR_HAS_LARGE_FILES 0
> typedef off_t apr_off_t;
>
> I think this is OK, isn't it?
writes:
> My user reported that an extra file existed in the repository after
> performing a merge (claiming this file was not in his working copy prior
> to the commit). My initial thought was they had done the merges out of
> sequence causing the deletion of a file before it was added, the use
Daniel Shahaf writes:
> [ summary for dev@: bug in trunk that doesn't reproduce in 1.6.16;
> I can reproduce it with trunk/ra_serf but not with trunk/ra_neon ]
>
> Aleksandr Platonov wrote on Thu, Apr 07, 2011 at 17:52:13 +0400:
>>
>> I build Subversion as a part of TortoiseSVN (see
>> http://to
"Bert Huijben" writes:
>> What I find is that the problem sometimes appears and sometimes does
>> not. It's not predictable either, repeating a failed export/checkout
>> will sometimes work and sometimes fail at a different place. That is
>> the case when I try that neon URL:
>>
>> svn: E20001
Philip Martin writes:
> I was getting those checksum errors while doing an export, I'm not sure
> how 3711 is relevant.
So I got an checksum error during an export using serf for the file
src/ne_uri.c. I compared the "bad" file in the export with a "good"
ver
Mark Phippard writes:
> On Tue, Aug 9, 2011 at 4:49 PM, wrote:
>
>> ** **
>>
>> Ok, I’ve tracked down which revision caused the problem. It happened in
>> rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion.
>> Ever since this change went in I am seeing subversion crash whe
writes:
> I am attaching a stack trace with symbols enabled.
Thanks!
> I'm using gcc. The default in the makefile.
I think RHEL may have come with two different gcc, a 3 series and a 4
series. What version does 'gcc -v' show?
> I am using the apr that you get from the get-deps.sh
> script.
Dave Huang writes:
> On Aug 10, 2011, at 4:51 PM, Philip Martin wrote:
>> convset looks to be corrupt, that value is way bigger than the other
>> pointer values. It looks like ASCII, "-ftu-nvs", but that probably
>> just means it's random.
>
> It&#x
Philip Martin writes:
> writes:
>
>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>> longer crashes.
>
> That suggests it could be a compiler bug.
The other flag you could try is to enable optimisation but to use
-fno-strict-aliasin
writes:
> It is set to 1
>>
>> Looking at the rest of the stack trace I would say this is the first
>> call to a utf8 conversion function that would have invoked
>> get_xlate_handle_node and I suspect it is that function that is going
>> wrong. At a guess something to do with the use of atomic_
Patrick Quirk writes:
> I upgraded to 1.7 yesterday when the new version of Tortoise came out,
> and used it with no issues last evening and today until I encountered
> this assertion:
>
> In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c'
>
Patrick Quirk writes:
>> Is the sqlite3 utility readily available on Windows? If it is then run:
>> sqlite3 .svn/wc.db "select * from work_queue"
>
> Yep, here's the output:
> 79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1)
> 80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.resx 1 0
Stefan Sperling writes:
> On Thu, Oct 13, 2011 at 04:28:21PM +0200, Daniel Sparing wrote:
>> Dear fellow subversion users,
>>
>> as requested by the error message, i would like to report an error as
>> the following:
>>
>> ---8<---
>> In file
>>
>> 'D:\Development\SVN\Releases\TortoiseSVN-1.7
Hyrum K Wright writes:
> Another option might be to run a pre-upgrade check to ensure this type
> of error doesn't exist, before we irrevocably upgrade (and potentially
> hose) the working copy.
This is happening during upgrade so the working copy remains a 1.6
working copy.
--
Philip
Patrick Quirk writes:
Is the sqlite3 utility readily available on Windows? If it is then run:
sqlite3 .svn/wc.db "select * from work_queue"
>>>
>>> Yep, here's the output:
>>> 79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1)
>>> 80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisp
Ed Hillmann writes:
> checking for a BSD-compatible install... build/install-sh -c
> configure: Apache Portable Runtime (APR) library configuration
> checking for APR... yes
> checking APR version... 1.4.5
> /u01/ct/ctapp/subversion-1.7.0/configure: bad substitution
>
>
> I can't see what is caus
sebb writes:
> In that case, either that is an insufficient check, or the upgrade
> fails to act correctly on the results of the check.
In what way? The upgrade detected the problem, stopped the upgrade and
left the 1.6 working copy unchanged apart from some files in .svn/tmp.
--
Philip
[Adding dev@s.a.o as I think this is a bug in the Subversion code,
although I don't know enough to be sure.]
Jean-Daniel Dupas writes:
>> Le 18 oct. 2011 à 18:39, Jean-Daniel Dupas a écrit:
>>
>>> After upgrading to svn 1.7, I encounter some very annoying issues.
>>> I have a web server with th
Andreas Krey writes:
> + svn commit -m 1
> Adding kadr.polon.p
> Transmitting file data .ld.so.1: svn: fatal: relocation error: file
> /export/home/krey/svn17/lib/libsvn_delta-1.so.0: symbol compressBound:
> referenced symbol not found
I think that is a zlib symbol. Subversion links
Les Mikesell writes:
> Perhaps it is obvious and known to you. I think the number of error
> reports on the list indicates that the scenarios that cause errors are
> not generally well understood.
The error in this case:
line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
foun
Stefan Sperling writes:
> On Fri, Oct 21, 2011 at 10:34:52AM +0100, Jon Nicoll wrote:
>> So, my question is: is there something in the 'svn commit' protocol
>> which causes the client process to do a lot of work, potentially
>> causing the client machine to run out of memory, up to one hour after
Jon Nicoll writes:
> So for now I would be best off to regard my 'initial working
> directory' as suspect, and if I checkout from the server into a new
> directory, that directory should be correct, yes?
You will probably need to run cleanup on the old working copy to remove
locks but it should
Philip Martin writes:
>>> Le 18 oct. 2011 à 18:39, Jean-Daniel Dupas a écrit:
>>>>
>>>> Before the update, this configuration were working fine. But after
>>>> the update, anytime the server receives a POST request (whatever the
>>>> p
Pecinovský Rudolf writes:
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\adm_ops.c'
>
> line 177: assertion failed (status == svn_wc__db_status_normal || status ==
> svn_wc__db_status_added)
> However the command line client tells:
>
> D:\Tvorba_PGM_SVN>svn
Ludescher Antal writes:
> In file included from subversion/libsvn_subr/sqlite.c:32:0:
> subversion/libsvn_subr/internal_statements.h:6:3: warning: missing
> terminating " character [enabled by default]
> subversion/libsvn_subr/internal_statements.h:8:4: warning: missing
> terminating " character
"Richard Millet" writes:
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\lib
> svn_wc\copy.c'
>
> line 491: assertion failed (child_status ==
> svn_wc__db_status_server_excluded)
Probably issue 4026:
http://subversion.tigris.org/issues/show_bug.cgi?id=4026
--
Philip
Stefan Sperling writes:
> On Mon, Oct 24, 2011 at 10:02:03AM -0700, Richard Millet wrote:
>> In file
>>
>> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\lib
>> svn_wc\copy.c'
>>
>> line 491: assertion failed (child_status ==
>> svn_wc__db_status_server_excluded)
>
> I
Mothmonsterman writes:
> Should this have been resolved with Issue 4015?
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4015
>
> On Oct 17, 4:30 pm, Mothmonsterman wrote:
>> same problem here..
>>
>> On Oct 4, 1:10 pm, Rolf Campbell
>> wrote:
>>
>> > When I try to update a working view
Jacob Weber writes:
> I want to pass the output of "svn diff OLD-URL NEW-URL" to a
> code-review tool, but I need to include the full path of each file
> in the ---/+++ headers.
>
> The paths in the output always seem to be relative to the directories
> you pass in. Is there a way to make it i
Mothmonsterman writes:
> No, it was the 2011-10-11 — 1.7.0
>
> I just noticed there is a 1.7.1 release, so I upgraded client to it...
> No dice, still have same issue. (svn, version 1.7.1 (r1186859)).
>
> It is a 1.6 checkout upgraded to 1.7.
>
> My setup is identical to the test case described i
Mothmonsterman writes:
> 2011-10-11 — 1.7.0 was used to do the upgrade. No release candidates
> were ever installed.
>
> On Oct 24, 5:28 pm, Philip Martin wrote:
>> Mothmonsterman writes:
>> > No, it was the 2011-10-11 — 1.7.0
>>
>> > I just notic
Mothmonsterman writes:
> External definition:
> C:\eclipse\workspaces_3_6\CADOC\eOMIS>svn propget svn:externals
> ^/eOMIS/trunk/src/a/b/c/SF02_SampleClass.java src/a/b/c/
> SF02_SampleClass.java
> ^/eOMIS/trunk/src/a/b/c/SF02_SampleServlet.java src/a/b/c/
> SF02_SampleServlet.java
> ^/eOMIS/trunk
Wabe W writes:
> First, please bear with my ignorance here. I only just figured out
> that I don't get a reply to my e-mail in my inbox. I'm apparently
> supposed to visit this page...
People are replying to utwente.nl address in your Reply-To header.
> Anyway, thank you for replying. To return
"Schoenbrun, Jason" writes:
> I was trying to checkout everything in our repository, from the very
> top. Got to 400 - 500 MB before getting this error.
> In file
>
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion
> \libsvn_wc\update_editor.c'
>
> line 1582: assertion f
Davor Barcan writes:
> During an update I received the following error:
>
> In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\update_editor.c'
> line 2898: assertion failed (status != svn_wc__db_status_normal)
>
> I did not see that error was reported pr
Stefan Sperling writes:
> With BDB repositories, it will not work, so you should dump/load.
Is that right? According to the documentation:
http://download.oracle.com/docs/cd/E17076_02/html/gsg/C/databaseLimits.html
the BDB database files are portable. I think the BDB environment files
are pl
Attila Nagy writes:
> I'm trying to update a working copy of some tens of GBs with svn 1.7.1
Did you upgrade with 1.7.0 or 1.7.1?
> $ svn up
> Updating '.':
> svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line
> 1582: assertion failed (action == svn_wc_conflict_action_edit ||
> a
"Schoenbrun, Jason" writes:
> I got the same error twice - once the first time I was doing that
> checkout, and then again when I checked out on top of an existing
> working copy.
>
> I'm not sure if it was checking out externals at the time.
There is not much I can do with the information you h
"Schoenbrun, Jason" writes:
> We have a few directories under the main repository URL - "trunk"
> worked, but the problem occurred in "legacy". It happens each time (2x?
> 3x?) in the same place.
If you just checkout "legacy", or "legacy/foo", or "legacy/foo/bar",
does the problem still occur?
"Schoenbrun, Jason" writes:
> Yes, it happens in all 3 scenarios.
>
> -Original Message-----
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: Wednesday, October 26, 2011 11:47 AM
> To: Schoenbrun, Jason
> Cc: users@subversion.apache.org
>
Attila Nagy writes:
> On 10/26/11 15:37, Philip Martin wrote:
>> Attila Nagy writes:
>>
>>> I'm trying to update a working copy of some tens of GBs with svn 1.7.1
>> Did you upgrade with 1.7.0 or 1.7.1?
> I've upgraded the WC with 1.7.0, then swi
Wabe W writes:
> I also tried a checkout of a(n existing) repository to a different
> location. I get the same error message when I try to update.
This is reproducible? You checkout some revision R1 and update to R2
and see the error?
Can you describe the changes between R1 and R2?
Is there a
Mark Phippard writes:
> I would imagine svn upgrade is almost entirely writes and I recall it does
> quite a few transactions. So couldn't the linear slow down just be based on
> the growth in the amount of bytes that are written to disk each time?
Yes, number of transactions matters a lot. Ho
Erwane Breton writes:
> On my client (windows 7 x64 tortoise SVN), i CAN commit with Tortoise
> 1.6.15 on my laptop but i CAN'T commit (or rename or delete) on my
> other computer with tortoise 1.7.1.22161
>
> The error is always the same
>
>> Commit
>> Commit failed (details follow):
>> '/svn/si
Attila Nagy writes:
> ZFS.
> It it worth to make benchmarks with this WC with 1.6 and 1.7? I so, I
> can try to find the time for it.
There are some reports that a mismatch between SQLite page size and ZFS
block size can cause performance problems and that better performance is
obtained when the
Mojca Miklavec writes:
> I'm experiencing some weird behaviour with SVN 1.7. The following
> sequence of commands fails to respect --depth=empty:
> svn co --depth=empty http://foundry.supelec.fr/svn/metapost
> svn up --depth=empty metapost/tags
>
> (you can use 'anonymous' as a username) Th
Wabe W writes:
>> This is reproducible? You checkout some revision R1 and update to R2
>> and see the error?
>>
>> Can you describe the changes between R1 and R2?
>
> I just did a checkout of the latest revision of the repository. So, if
> I click update the chances are large that there is no n
Philip Martin writes:
> I'm surprised it happens when the update makes changes to the working
> copy, I can't see how close_edit is called in that case.
Oops! I meant to say I can't see how end_directory_update is called.
--
Philip
Nrupen Kantamneni writes:
> Now from my mobile browser, I should be able to upload a document to
> the server after downloading the file and making changes. That would
> be more convenient for me to manage the files from where ever I am.
> Hope I am clear in clarifying my use model
Perhaps autov
Stefan Sperling writes:
> On Tue, Nov 01, 2011 at 11:31:35AM -0600, michael_rytt...@agilent.com wrote:
> Note that I am not going to commit this as is.
> It just tests whether the overhead of sorting paths in sqlite matters
> much on NFS.
>
> Index: subversion/libsvn_wc/wc-queries.sql
> =
Stefan Sperling writes:
> On Tue, Nov 01, 2011 at 06:29:59PM +0000, Philip Martin wrote:
>> I put in the ORDER BY to preserve the parents before children
>> notification used by 1.6. I wonder if that notification order is
>> important?
>
> See r1196191.
> It should
Wabe W writes:
>> I assume you are using some sort of server. Which version of Subversion
>> is the server running?
> It is 1.0.8 (2004)
That's old (very old) and unsupported. The client should still work but
I haven't built or used 1.0.x for years.
>>Is it a googlecode server? Are you us
Tomáš Klinkovský writes:
> starting from svn 1.7 I cannot make "svn update" anymore on Windows 7,
> 64bit.
>
> C:\Users\tomas\Documents\xxx>svn --version
> svn, version 1.7.1-SlikSvn-1.7.1-X64 (SlikSvn/1.7.1) X64
> compiled Oct 26 2011, 14:18:24
>
> C:\Users\tomas\Documents\xxx>svn update
>
Tomáš Klinkovský writes:
> My server is also very old:
>
> $ svn --version
> svn, version 1.0.9 (r11378)
> compiled Oct 14 2004, 10:04:20
>
> But I don't access it through Apache, I have the Subversion daemon
> running and I use the "svn:" protocol.
>
> Can I provide any other help?
I can
Wabe W writes:
> So, we just have to update the server and see if the problem is solved?
It's issue 4048, it may get fixed in a 1.7.x release:
http://subversion.tigris.org/issues/show_bug.cgi?id=4048
--
Philip
Michaël Bruneel writes:
>
> DAV svn
> SVNPath /srv/svnroot/myproject
>
Given and an URL '/foo/bar/zig/zag' mod_dav_svn
treats '/foo/bar' as the path to the repository and '/zig/zag' as the
path inside the repository.
How would you Location work? Where does '/foo/bar/zig/
"Tony Butt" writes:
> On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote:
>> Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100:
>> > I tried to edit the log message of a commit made with svn+ssh://, using
>> > http:// access, and failed. Now the strange thing, after changing a
>> > diffe
Neil Bird writes:
> Am I just doing something wrong?
You are trying to make a file external point to a file in a different
repository, that is not supported.
--
Philip
Bastian Holtermann / SOREL GmbH writes:
> I got the problem that when I checkout some code that is using
> externals with a special specified revision of that external to be
> checked out svn checks out the head revision in stead of the specified
> revision number.
Agreed, that is a bug. I've r
Ulrich Eckhardt writes:
> Am 10.11.2011 10:07, schrieb JESUS LUNAR PEREZ:
>> 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.
>
>
>> Bu
Gunnar Dalsnes writes:
> REM change this to the dir you are running the script from
> set wd=c:/temp/test
>
> svnadmin create repo
>
> svn mkdir file:///%wd%/repo/trunk -m test
>
> svn co file:///%wd%/repo/trunk trunk1
> svn co file:///%wd%/repo/trunk trunk2
trunk2 is an empty directory at r1
>
Neil Bird writes:
> Having just done a couple of commits (after an update), I did some
> work on a file then went to commit again (no 2nd. update) and
> TortoiseSVN reported no changes.
>
> A command line 'svn status .' is giving me:
>
> svn: E200030: database disk image is malformed
> svn: E
Neil Bird writes:
> "*** in database main ***
> On tree page 40898 cell 60: 2nd reference to page 325
> On tree page 40898 cell 60: Child page depth differs
> On tree page 40898 cell 61: Child page depth differs"
> "rowid 14277 missing from index sqlite_autoindex_PRISTINE_1"
> "rowid 14278 missin
"Jens Geyer" writes:
> I can confirm that.
> Deleting is only possible if the user has write permnissions on the
> ENTIRE path.
>
> / top/subdir/mypath
>
> In order to delete mypath, the user needs write permission on
>
> /
> /top/subdir
> /top/subdir
> /top/subdir/m
Stefan Sperling writes:
> On Thu, Nov 10, 2011 at 05:25:27PM +0000, Philip Martin wrote:
>> I wonder if there is an upper/lower case problem somewehere in your
>> authz file? Or perhaps in the Subversion authz code?
>
> If so, this is likely due to the change in case-awa
Bostjan Skufca writes:
> Well, in my case, it is all lower-case all the time. Is there any other way
> to double check this? I checked with "svn ls ..." every component of path
> to be lower case, and it was. authz file is also in lower case completely.
> Still, delete as described before does no
"Zibetti Paolo" writes:
> With Subversion version 1.6.x, I could add the "--quiet" switch to the
> "svn copy" command to suppress all output in case the command succeeds.
>
> With Subversion version 1.7.1 "svn copy --quiet ..." always prints
> informational messages such as "Committed revision 4
Gunnar Dalsnes writes:
>>>
>>> REM tree conflict
>>>
>>> svn resolve --accept=working dir1
>> Did you miss a step?
> No, nothing is missed, but it seems this line is useless (but
> harmless). The problem appears regardless.
>> trunk2 is still an empty directory at r1, how can
>> that cause a co
Philip Martin writes:
> The merge creates an added directory wc/D (copied from /T/D in the
> repo). This conflicts with the directory D added by the update (which
> is /X/B in the repo) so a tree conflict is created. Note that wc/D is
Typo: /X/B should be /B/D.
> marked
Bostjan Skufca writes:
> Nope, first step already fails (commit 3) if there are "[/]\n* = r" lines
> present in authz file.
>
> It works if I create authz file like this (note the usage of rw everywhere):
> [/A/B]
> pm = rw
>
> [/X/Y]
> pm = rw
> -
>
>
> It DOES NO
Michaël Bruneel writes:
> IMHO, given and URL '/', mod_dav_svn
> should be able to understand the regular expression and treat '/' as
> both the path to the repository and the path inside the repository. It
> should not use raw '(?!viewvc)' data as it does now.
That's only one case out of man
1:27:52.238178Z - testuser1 svn check-path /X/Y@19
> 32558 2011-11-14T11:27:52.238221Z - testuser1 svn reparent /A/B
> 32558 2011-11-14T11:27:52.238256Z - testuser1 svn check-path /A/B/E@19
> ----------
>
> On 14 November 2011
Bostjan Skufca writes:
> Authz is correct, I just changed pm to testuser1 because user already
> existed and because it is bad to use auth credentials which have been sent
> to mailing list on a public server:)
But it makes it harder for us to work out whether you are doing things
correctly. I
vincze béla writes:
> using tortoise svn 1.7.1.22161 64bit on Win7. on updating a certain
> folder, i've got the following crash message:
>
> In file
>
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\update_editor.c'
> line 1310: assertion failed (added_statu
Bostjan Skufca writes:
> This does not work:
>
> svn cp svn://127.0.0.1/X/Y ^/A/B/C -m Test
> Authentication realm: Test repo
> Password for 'testuser1':
> svn: E220004: Access denied
The difference is that you are doing:
svnserve -dr svn
svn cp svn:/localhost/X/Y ^/A/B/C
while my example was
Ethan Bradford writes:
> I upgraded a tree from 1.6.x directly to 1.7.1 and I'm getting this, so the
> bug (or a similar one) definitely persists.
>
> I've got very big trees, so checkouts take most of a day, so redoing the
> checkout isn't so convenient.
What did the 1.6 working copy look like?
Ethan Bradford writes:
>> Do you have the sqlite3 tool available to query the 1.7 working copy?
>>
>> sqlite3 .svn/wc.db "select count(*) from nodes where op_depth > 0"
>>
>
> I installed sqlite3 to check this. The answer it gets is 0.
Fine. Next:
sqlite3 .svn/wc.db "select * from work_queue"
Neil Bird writes:
>> Copy NODES_COPY into NODES:
>> sqlite3 .svn/wc.db "insert into NODES select * from NODES_COPY"
>
> Oops. “Error: database disk image is malformed”.
>
> Which is a bit odd, since we copied NODES to NODES_COPY OK, and have
> since re-created NODES!
Odd indeed. Some sort
Frank Liu - Orite Group writes:
> In file
>
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\workqueue.c'
> line 672: assertion failed (checksum != NULL)
That's the same error as reported in this thread:
http://mail-archives.apache.org/mod_mbox/subversion-
Ethan Bradford writes:
>> sqlite3 .svn/wc.db "select * from work_queue"
>
> 3|(file-install 59
> DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED] 1 0 1 1)
>
>> sqlite3 .svn/wc.db "select * from nodes where
> local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'"
Ethan Bradford writes:
> I don't know what the server version is. cURL won't accept an svn: URL.
Ah! svnserve. Then "telnet server.com 3690" will get the handshake
which will tell us something.
> Using the repo browser I can see the whole history. There are just two
> versions of this file,
Philip Martin writes:
>> I hate to confess to such absent mindedness, but I may have "svn delete"ed
>> this file. I see that I don't have a local copy of it, which supports that
>> theory. If I did that, I didn't commit the change -- the repository still
&
Aleksandr Sidorenko writes:
> I tried changed the permissions on the repository to be more permissive, and
> changing the user/group of the Apache server: no help.
>
> I also tried recompiling from source, but that did not help either.
>
> To recap, I am getting this warning after every commit s
Aleksandr Sidorenko writes:
> Rebuilt, now I get this message on post-commit:
>
> Warning: post commit FS processing had error:
> Couldn't perform atomic initialization
It could be the atomic functions failing, but more likely it's still a
DB problem. Please add this patch as well:
Index:
Aleksandr Sidorenko writes:
> But it seems it's not this error that is triggered; it's the one a few lines
> down (I changed the error message to detect it):
>
> #if APR_HAS_THREADS
> /* Wait for whichever thread is performing initialization to finish. */
> /* XXX FIXME: Should we have a max
"Bert Huijben" writes:
> You get in this branch if a previous atomic initialization call failed: the
> callback function failed and returned an error. This result is then ignored
> in some code paths.
>
> It is most likely not caused by the atomic operations failing itself, but
> more likely by a
Aleksandr Sidorenko writes:
> The sqlite command worked (I see the expected output), but I suspect that's
> because the rep-cache.db file was already there (since 1.6.12). If I move it,
> though, the file is NOT recreated.
>
> greping through /proc/xxx/maps gives me the following:
>
> 2a96fc400
Aleksandr Sidorenko writes:
> On 2011-11-16, at 11:15 , Philip Martin wrote:
>
>>> ...
>>
>> Try this patch:
>>
>> Index: subversion/libsvn_fs_fs/fs_fs.c
>> ===
>> --- su
Attila Nagy writes:
> I use pysvn for this and basically the code looks like this (in python):
> def update_perms():
> for path in propchg:
> proplist = svn.propget('file:permissions', path)
> if not os.path.islink(path) and proplist.has_key(path):
> set_perms(path
Sergey Skvortsov writes:
> Also, in 1.7 reading repos is working fine:
>
> "OPTIONS /svn/foo/bar HTTP/1.1" 200
> "REPORT /svn/foo/bar/!svn/me HTTP/1.1" 200
>
> but only POST fails:
> "POST /svn/foo/bar/!svn/me HTTP/1.1" 500
>
> So the problem is not in Apache or configuration but in mod_dav_svn
[Adding dev]
Philip Martin writes:
> Sergey Skvortsov writes:
>
>> Also, in 1.7 reading repos is working fine:
>>
>> "OPTIONS /svn/foo/bar HTTP/1.1" 200
>> "REPORT /svn/foo/bar/!svn/me HTTP/1.1" 200
>>
>> but only POST fails:
>&
Philip Martin writes:
> [Adding dev]
Gah! Got the address wrong. I'll start a thread on dev.
--
Philip
Stefan Sperling writes:
> How do we avoid ambiguity when handling requests to nested Locations?
> How can a client access a folder /bar inside a repository at Location /svn
> if another repository exists at a nested Location /svn/bar?
Yes, I was surprised too! If we assume that /svn and /svn/fo
Attila Nagy writes:
> On 11/16/11 18:40, Philip Martin wrote:
>> Attila Nagy writes:
>>
>>> I use pysvn for this and basically the code looks like this (in python):
>>> def update_perms():
>>> for path in propchg:
>>>
Stefan Sperling writes:
> Yes, of course it works with SVNParentPath. But I suspect that is
> a result of implementation rather than concious design.
Perhaps, but the line that stops it working looks like an outright bug.
newconf->root_dir = INHERIT_VALUE(child, parent, root_dir);
The orde
1 - 100 of 694 matches
Mail list logo
