Re: www.apache.org

[Greg Stein]

On Tue, Mar 2, 2010 at 02:18, Lieven Govaerts  wrote:
> On Tue, Mar 2, 2010 at 5:02 AM, Greg Stein  wrote:
>> Hey all, FYI:
>>
>> I just updated www.apache.org to include Subversion in the navigation
>> menu, along with tweaking the list of officers on
>> www.apache.org/foundation. If you see other places on the main site
>> (or elsewhere) that require updating, then please let me know.
>>
>> (if you don't see it right *now* ... that's cuz it is pending a 
>> sync/propagate)
>>
>> Thanks,
>> -g
>
> A search for "Abdera -abdera.apache.org -issues.apache.org
> -cwiki.apache.org -svn.apache.org -Subversion" results in:
>
> http://projects.apache.org/indexes/pmc.html
> http://projects.apache.org/indexes/category.html
> http://projects.apache.org/pmcs.html
> http://www.apache.org/foundation/marks/list/
> http://www.apache.org/licenses/exports/

Ah! Nicely found. I think the projects pages are auto-generated, but
certainly something to get cranking.

> Can we also remove Subversion from the incubator page? Or is that to early?

Yup. I'll move us to "graduated" status within the incubator pages.

Thanks!
-g

Re: www.apache.org

[Lieven Govaerts]

On Tue, Mar 2, 2010 at 5:02 AM, Greg Stein  wrote:
> Hey all, FYI:
>
> I just updated www.apache.org to include Subversion in the navigation
> menu, along with tweaking the list of officers on
> www.apache.org/foundation. If you see other places on the main site
> (or elsewhere) that require updating, then please let me know.
>
> (if you don't see it right *now* ... that's cuz it is pending a 
> sync/propagate)
>
> Thanks,
> -g

A search for "Abdera -abdera.apache.org -issues.apache.org
-cwiki.apache.org -svn.apache.org -Subversion" results in:

http://projects.apache.org/indexes/pmc.html
http://projects.apache.org/indexes/category.html
http://projects.apache.org/pmcs.html
http://www.apache.org/foundation/marks/list/
http://www.apache.org/licenses/exports/

Can we also remove Subversion from the incubator page? Or is that to early?

Lieven

www.apache.org

[Greg Stein]

Hey all, FYI:

I just updated www.apache.org to include Subversion in the navigation
menu, along with tweaking the list of officers on
www.apache.org/foundation. If you see other places on the main site
(or elsewhere) that require updating, then please let me know.

(if you don't see it right *now* ... that's cuz it is pending a sync/propagate)

Thanks,
-g

Re: memory leak? ref: merge test 4

[Greg Stein]

This problem was caused by the tweak on the APR 1.3.x branch to put
hash data into a subpool. I've updated my 1.3 installation to tip of
the branch, which backed that change out.


On Sun, Feb 21, 2010 at 21:32, Greg Stein  wrote:
> Those errors might be from the MacOS C library.
>
> So I looked into this some more. Backdating to r886351 (when we first
> bumped to format 16) would cause the problem to core dump, rather than
> some weird endless hang. Bisecting the changes, I find that r906110 is
> where the code switches from a core dump to a hang. It apparently
> tickles wc_db in a slightly different way, and alters the resulting
> symptom of some underlying double-free or somesuch.
>
> Gotta investigate further. See if I can put in some early checks for
> improper reuse or pool lifetime issues. I think the errors may be
> creeping up around pool-destroy time (and trying to access the wc_db
> during this time, while it is in partial-readiness).
>
> Cheers,
> -g
>
> On Thu, Feb 18, 2010 at 11:13, C. Michael Pilato  wrote:
>> I'm not seeing this problem, but then I don't think I'm setup to generate
>> stderr spam on malloc/free errors (via the likes of "MALLOC_CHECK_=1" in the
>> environment or somesuch).
>>
>> Greg Stein wrote:
>>> I think the memory usage might actually be our test harness attempting
>>> to read all of the (stderr) output into memory. Thousands and
>>> thousands of lines that read:
>>>
>>> svn(56985,0xa0634720) malloc: *** error for object 0x817a00: double free
>>> *** set a breakpoint in malloc_error_break to debug
>>>
>>> So maybe svn isn't consuming memory, but is simply generating a
>>> hojillion of these error lines. I forced an abort/coredump, and found
>>> this stack:
>>>
>>> #0  0x952e329a in write$NOCANCEL$UNIX2003 ()
>>> #1  0x9538f3ce in malloc_destroy_zone ()
>>> #2  0x9538e8e3 in malloc_zone_print_ptr_info ()
>>> #3  0x9538e943 in malloc_printf ()
>>> #4  0x9538941a in scandir$INODE64 ()
>>> #5  0x952b3523 in malloc_zone_free ()
>>> #6  0x952b338d in free ()
>>> #7  0x004d230c in apr_allocator_destroy (allocator=0x502010) at
>>> memory/unix/apr_pools.c:134
>>> #8  0x000101b5 in main (argc=11, argv=0xb0ac) at 
>>> subversion/svn/main.c:2288
>>>
>>> Any ideas?
>>>
>>> Cheers,
>>> -g
>>>
>>> On Wed, Feb 17, 2010 at 20:07, Greg Stein  wrote:
 I'm running into a problem with merge test 4. Some kind of memory
 leak, or other memory double-free or somesuch.

 During the 'svn switch', it just seems to head off into la-la land.
 Consumes a TON of memory before I kill it off.

 Has anybody seen this? Ring any bells?

 Thx,
 -g

>>
>>
>> --
>> C. Michael Pilato 
>> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>>
>>
>

Re: svn commit: r917772 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/callback/ src/org/tigris/subversion/javahl/ tests/org/apache/subversion/javahl/

[Blair Zajac]

On 03/01/2010 02:46 PM, hwri...@apache.org wrote:

Author: hwright
Date: Mon Mar  1 22:46:45 2010
New Revision: 917772

URL: http://svn.apache.org/viewvc?rev=917772&view=rev
Log:
JavaHL: Return properties as byte[] throughout the callback interfaces.

We use byte[] in place of String because there could be binary data in the
property, and the conversion to String would truncate the property at any
NULL bytes.



Plus the conversion from byte[] to String depends upon the platform's 
default character set.


I see there's a number of String's constructed from the byte[].  Those 
methods should take an additional java.nio.charset.Charset and then pass 
it's name to the String() constructor.  I don't believe there should be 
any String's constructed without a Charset argument.


Maybe the svn:date we can presume a UTF-8 character set, but the 
svn:author, svn:log we shouldn't.


Regards,
Blair

Re: [PATCH] WC-NG properties API - complete doc strings

[Greg Stein]

On Mon, Mar 1, 2010 at 07:23, Julian Foad  wrote:
> For review, please.  The patch below aims to provide complete doc
> strings for (the existing implementation of) the WC-NG properties API.

Looks great, thanks.

> I assume "properties" refers to regular, versioned properties
> throughout.

Yes.

> I checked the implementation with regard to returning an error when the
> node is not found.

It should always return an error. We were very inconsistent before,
and my intent was to error in all cases when a node is not found
(thus, my slight concern around the read_kind() function).

If it doesn't error, then that should be considered a bug.

> I believe svn_wc__db_base_get_props() is meant to return an empty
> (non-NULL) hash to represent "no properties", both because that's

Correct.

> consistent with the input and outputs of the rest of these functions and
> because the rest of these functions never write "null" to the
> "properties" column of the BASE table when writing an empty set of
> properties.  The non-nullness of that SQL column is not (yet) documented
> so I am not certain that there are no other functions that could write
> "null".

A null value in ACTUAL_NODE.properties means "no changes w.r.t the
pristine properties". Any value in there is the complete set of
(changed/deleted/added) properties.

I don't think that a null value in WORKING_NODE or BASE_NODE makes
sense. We could interpret that as "incomplete", or as a short-form for
"no properties". iirc, a skel for empty-property-hash is "()" (ie.
just 2 bytes).

My belief is that nodes "shouldn't" have incomplete data. That we
should create a node when we have all of its data. wc-1 and Editor v1
don't behave that way, however, so we're kind of stuck until we can
get much further into rewriting those processes. This is also why I
want to see all of a directory's child names at directory creation
time -- you then know everything about the directory (though each
child is incomplete because it is just a name).

>...

Cheers,
-g

Re: WC-NG - Doc strings and API design

[Greg Stein]

Thanks!

The current stuff has worked when it was just Hyrum and I, but you're
right: as we scale up the number of people, they become more important
to do "now" rather than "later".

Most of the wc_db "operation" functions are unknown since we haven't
tried to implement around them. Even the functions for maintaining the
BASE nodes aren't really used. One particular pattern missing across
the entire API is passing in an svn_skel_t for one or more work items
to be transactionally inserted into WORK_QUEUE at the same time as the
other database operations are performed. The work item(s) describe
filesystem changes that need to occur to bring the on-disk world
inline with the database view of the world.

(compared to today, where the work items kind of do a mix of
filesystem and database changes; they should only be doing filesystem
in the future)

Cheers,
-g

On Mon, Mar 1, 2010 at 08:02, Julian Foad  wrote:
> We need doc strings.  We always do, but especially at this point we need
> them in order to assist other people in joining the effort to implement
> WC-NG.  I think one of the most useful things I can do at this point is
> help write them.
>
> Doc strings go hand in hand with API design, as I'm sure we all know
> (subconsciously at least), so as I try to write them I am necessarily
> examining and trying to guess and then sometimes suggesting changes to
> the API design.  Sometimes that will be a separate step, sometimes part
> of the same patch.
>
> Most of the APIs I'm looking at are private and sparsely documented, and
> 'wc_db.h' has a comment ending, '... do not want to doc until it feels
> like it is "Right"'.  It seems the time is now Right to consolidate,
> document, and change where better options are now apparent.  I don't
> want to step on anyone's toes or make gratuitous changes, so let me know
> if I seem to be doing so.
>
> And I'm not going to do the whole API on my own.  I'll do some parts.
> Please step in and fix up another part of it if you can.
>
> - Julian
>
>
>

Re: Web-Site: Linking to CHANGES file for different releases

[Karl Heinz Marbaise]

sorry...not answered to the list.


Hi Michael,


Yeah, the great thing about always pointing at trunk is that it 
contains all
the change records, so if you want to see what happened in other 
releases,

the info is readily available.

The bad thing is that it contains all the change records, so if you don't
want to see what happened in other releases, you gotta dig some for the
release you do care about.

Yes...that's a point...


But here's my case for *not* linking against the tagged CHANGES 
items:  we
only push out new release notes for big X.Y.0 releases, yet folks 
refer to

them as an explanation of what they are getting with any installation of
Subversion from the X.Y lineage.  It would be weird to download 
Subversion

1.6.9, read the 1.6 release notes, and then get pointed to a quite-stale
1.6.0 CHANGES list.  So if we're going to do anything around these 
parts, we

should be pointing to the CHANGES files as they exist in the release
*branches* (e.g. branches/1.6.x/CHANGES).

That's a better solution for this...

I would vote for that ...

+1 from me...


Kind regards
Karl Heinz Marbaise


--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

Re: svn commit: r917512 - in /subversion/trunk/subversion/mod_dav_svn: mirror.c mod_dav_svn.c

[Blair Zajac]

Kamesh Jayachandran wrote:

Modified as suggested.


Thanks!

Blair

Re: pristine store design

[Stefan Sperling]

On Mon, Mar 01, 2010 at 06:14:33PM +, Julian Foad wrote:
> On Thu, 2010-02-18, Neels J Hofmeyr wrote:
> > The one thing left now is:
> > > Can someone explain a motivation for even creating a database row before
> > > the pristine file is moved into place in the pristine store? I currently
> > > don't see why it can't be way simpler.
> [...]

> "Simultaneous or multi-threaded clients" would be my first reaction to
> that particular question.

If two threads write to the same pristine, the content written
will be the same (except in case of a SHA1 checksum collision
which we choose to ignore). So, thread 1 writes to a tempfile, and
when it's done, it moves the tempfile into place. The new filename
of the tempfile being based on the SHA1 sum of the written content.
If thread 2 does the same concurrently, the end result will be the
same -- the file will only exist once at its SHA1 sum name.

Of course, writing the same pristine more than once is redundant.
So we could try to optmize this redundancy away. But I don't think
it is worth it. If you're only talking about threads within a single
process, it's fairly easy. But if you're talking about multiple
processes using the same pristine store concurrently with mutual
exclusion, you need inter-process communication to deal with stale locks.
What is a process supposed to do with a locked pristine store, if
it has no way of telling what happened to the process which locked
the pristine store? What if the other process has chrashed?

Stefan

Re: Broken website link report ala 'webcheck'

[Karl Heinz Marbaise]

Hi there,

first patch for fixing the webcheck bugs.

Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de
Index: publish/docs/release-notes/1.5.html
===
--- publish/docs/release-notes/1.5.html (revision 917589)
+++ publish/docs/release-notes/1.5.html (working copy)
@@ -1249,7 +1249,7 @@
 databases need to kept in sync via post-lock and post-unlock hooks on
 the master pushing the lock state to the slaves.  (Username
 preservation is left as an exercise to the reader.  Translation: patches to these notes are most
+href="/docs/community-guide/mailing-lists.html#sending-patches">patches to 
these notes are most
 welcome.)  If the lock database is not propagated, users will not
 be able to accurately determine whether a lock is
 held — but locking will still work.
Index: publish/docs/release-notes/1.6.html
===
--- publish/docs/release-notes/1.6.html (revision 917589)
+++ publish/docs/release-notes/1.6.html (working copy)
@@ -470,7 +470,7 @@
 
 
 Need to document possible incompatibilities (see
-this
+http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=86142";>this
 thread)
 
   
Index: publish/faq.html
===
--- publish/faq.html(revision 917589)
+++ publish/faq.html(working copy)
@@ -1109,7 +1109,7 @@
 the volume of renames used internally in Subversion when checking out
 files, some users have reported that 'subtree checking' should be
 disabled (it's enabled by default).  Please see http://nfs.sourceforge.net/nfs-howto/server.html"; >NFS Howto
+href="http://nfs.sourceforge.net/nfs-howto/ar01s03.html"; >NFS Howto
 Server Guide and exports(5) for more information on how to
 disable subtree checking.
 
@@ -1343,7 +1343,7 @@
 title="Link to this section">¶
 
 
-FIRST, read the Hacker's Guide to
+FIRST, read the Hacker's Guide to
 Subversion. 
 
 Once you've digested that, send a mail to the dev list with the
@@ -1367,7 +1367,7 @@
 
 Of course, the email you send should contain a nice long
 explanation about what the patch does, as per the
-Hacker's Guide to Subversion, but you
+Hacker's Guide to Subversion, but you
 already know that, since you read and completely understood
 it before actually hacking the code, right? :)
 
@@ -3897,7 +3897,7 @@
 
 
 A careful examination of the Windows API documentation regarding http://msdn2.microsoft.com/en-us/library/aa365247.aspx#maximum_path_length";
+href="http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath"
 >Naming a File reveals the most common reason why this happens. In
 short, you can address significantly longer path names when using the
 Unicode versions of the Windows path functions, and providing absolute

Web-Site Bugs

[Karl Heinz Marbaise]

Hi,

i have checked the link check list and found the following in the 
subversion-site/publish/docs/community-guide/building.part.html file...

which contains the following links:

 start snippet -
Various people have arranged for the automated test framework to
run at regular intervals on their own machines, sending the results to
the svn-break...@subversion.tigris.org mailing list.  The more
different platforms the tests run on, the more quickly we can detect
portability bugs in Subversion.  If you'd like to send svn-breakage
messages too, use the href="http://svn.apache.org/repos/asf/subversion/trunk/tools/test-scripts/svntest/"; 


>svntest framework (start at the href="http://svn.apache.org/repos/asf/subversion/trunk/tools/test-scripts/svntest/README"; 


>README).
- end snippet -

The problem is that the links into the repository do not exist (may be i 
oversight something)...


Can someone of the dev's point me to the correct location to fix the 
link problem ?


Many thanks in advance

Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

Re: pristine store design

[Julian Foad]

On Thu, 2010-02-18, Neels J Hofmeyr wrote:
> Great, moving forward fast on pristine design questions!

Hi Neels.

Did you start working the new knowledge into a document?  Lots of stuff
was said in this thread and it would be useful to see where we are at.
I have a couple of comments.


THE PRISTINE-WRITE API

I was thinking about the "write" API and how an API designed around a
stream is surely better than one designed around "tell me the path where
I can put a file".

The objection to "give me a writable stream and I'll write to it" was
that the stream close handler wouldn't know whether the stream was
closed after a successful write or because of an error.  We can rectify
this by adding a second step: require the caller to call a special
"commit" API to close the stream on success, and any other way of
closing the stream would abandon the new content.

  // Caller passes the checksum if it knows it, or passes NULL and
  // the store in that case will calculate the checksum.
  stream = pristine_start_new_file(expected_checksum);

  [caller writes to stream]

  // Now the store commits the new text, verifies the checksum
  // (if it was given an expected one) and returns it.
  new_checksum = pristine_close_new_file(stream);

Now let's examine the ways in which a caller might want to give new
content to the store:

  1. Caller asks for a writable stream and pushes content to that, then
calls a "commit" function.

  2. Caller has a readable stream and wants the store to pull from that.

  3. Caller has a (non-temporary) file and wants the store to read from
that file.

  4. Caller has to create a temporary file for reasons beyond its
control (output of an external tool perhaps) and wants the store to take
the entire file by an atomic move if possible. This is the case where it
would be more efficient if it know where to put the file in the first
place.

The caller can easily implement 2 and 3 in terms of an API that provides
1, so that just leaves 1 and 4 that are worthwhile as an API.

I feel that (1) is by far the more important one to have, and (4) is a
specialist optimisation.


VERIFYING CHECKSUMS

I didn't read everything you were discussing but I got worried by
hearing about providing options for the caller to request checksums to
be verified or not per call.  That sounds like too much complexity.  I'm
sure we should start with a global compile-time verification enable
switch, and if we really find we need more fine-grained control then we
should consider how to provide it then.  It might not need an API flag:
for example we might decide it should automatically verify on the first
read and once in every hundred reads, or all sorts of internal
possibilities like that.


> The one thing left now is:
> > Can someone explain a motivation for even creating a database row before
> > the pristine file is moved into place in the pristine store? I currently
> > don't see why it can't be way simpler.
[...]

I would just write it down the way you think it should be in the main
flow of your document, and mention outstanding questions like this in
notes.

"Simultaneous or multi-threaded clients" would be my first reaction to
that particular question.

- Julian

RE: svn commit: r917512 - in /subversion/trunk/subversion/mod_dav_svn: mirror.c mod_dav_svn.c

[Kamesh Jayachandran]

Modified as suggested.

Thanks
With regards
Kamesh Jayachandran

-Original Message-
From: Blair Zajac [mailto:bl...@orcaware.com]
Sent: Mon 3/1/2010 10:47 PM
To: kame...@apache.org
Cc: dev@subversion.apache.org
Subject: Re: svn commit: r917512 - in /subversion/trunk/subversion/mod_dav_svn: 
mirror.c mod_dav_svn.c
 
kame...@apache.org wrote:
> Author: kameshj
> Date: Mon Mar  1 13:15:58 2010
> New Revision: 917512
> 
> URL: http://svn.apache.org/viewvc?rev=917512&view=rev
> Log:
> Follow-up to r916286.
> 
> * subversion/mod_dav_svn/mod_dav_svn.c
> (create_dir_config):
> * subversion/mod_dav_svn/mirror.c
> (dav_svn__location_in_filter, dav_svn__location_body_filter):
> Use 'svn_uri_canonicalize' on url paths.

A minor comment on the log messages.  The lines beginning with () are indented 
two spaces and each source file has one vertical whitespace separating it from 
other files.  This makes it much easier to visually parse the log message to 
quickly see what's being changed:

* subversion/mod_dav_svn/mod_dav_svn.c
   (create_dir_config):
   Use 'svn_uri_canonicalize' on url paths.

* subversion/mod_dav_svn/mirror.c
   (dav_svn__location_in_filter, dav_svn__location_body_filter):
   Use 'svn_uri_canonicalize' on url paths.

Regards,
Blair

Re: svnserve under Linux inetd hangs, burning CPU cycles, under too low TCP-sendbuffer.

[Philip Martin]

"Dr. Andreas Krüger"  writes:

>> strace should show you whether or not the server is writing any
>> data, and whether or not the writes are failing.   Is it writing any
>> data at all?
> Yes.
>
>> Are the writes failing?
>
> No!

How big are the writes?  In my test I saw things like:

write(4, " ) ) ( textdelta-chunk ( 2:c1 9:\0"..., 4096) = 4096 <0.074322>
write(4, 
"a\256\372wS|:\35\330\6\353\201\321k\27\327\360\307\325e\337\267\372\256\224\"\305\251\5\227\303Z]"...,
 98422) = 98422 <2.678038>

> (I had actually mentioned that much in an earlier mail.)
>
> Could indeed be an openvpn bug, somehow.
>
> But why would subversion keep eating CPU cycles?

Somebody (you probably) needs to debug it.  There are loops in
apr_socket_send but they should only apply if the writes are failing.
In one of your earlier mails you indicated there were a mixture of
read, write and poll calls so that seems to indicate that it's looping
in the Subversion code rather than the apr code.  If the write system
calls don't fail then svnserve will keep on going.  As I understand it
OpenVZ involves a custom kernel with it's own network drivers, perhaps
the write syscall is doing something unexpected.

-- 
Philip

Re: svn commit: r917512 - in /subversion/trunk/subversion/mod_dav_svn: mirror.c mod_dav_svn.c

[Blair Zajac]

kame...@apache.org wrote:

Author: kameshj
Date: Mon Mar  1 13:15:58 2010
New Revision: 917512

URL: http://svn.apache.org/viewvc?rev=917512&view=rev
Log:
Follow-up to r916286.

* subversion/mod_dav_svn/mod_dav_svn.c
(create_dir_config):
* subversion/mod_dav_svn/mirror.c
(dav_svn__location_in_filter, dav_svn__location_body_filter):
Use 'svn_uri_canonicalize' on url paths.


A minor comment on the log messages.  The lines beginning with () are indented 
two spaces and each source file has one vertical whitespace separating it from 
other files.  This makes it much easier to visually parse the log message to 
quickly see what's being changed:


* subversion/mod_dav_svn/mod_dav_svn.c
  (create_dir_config):
  Use 'svn_uri_canonicalize' on url paths.

* subversion/mod_dav_svn/mirror.c
  (dav_svn__location_in_filter, dav_svn__location_body_filter):
  Use 'svn_uri_canonicalize' on url paths.

Regards,
Blair

Web-Site Bugs - Release History.

[Karl Heinz Marbaise]

Hi,

so the next things
Attached a patch for the

publish/docs/release-notes/1.1.html
publish/docs/release-notes/1.2.html
publish/docs/release-notes/1.3.html

file.

Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de
Index: publish/docs/release-notes/1.1.html
===
--- publish/docs/release-notes/1.1.html (revision 917589)
+++ publish/docs/release-notes/1.1.html (working copy)
@@ -84,8 +84,8 @@
repository over a network filesystem, and no more database "wedges"
needing recovery.  You can read the full list of
advantages/disadvantages at http://svn.collab.net/repos/svn/trunk/notes/fsfs";
->http://svn.collab.net/repos/svn/trunk/notes/fsfs
+   href="http://svn.apache.org/repos/asf/subversion/trunk/notes/fsfs";
+>http://svn.apache.org/repos/asf/subversion/trunk/notes/fsfs
 
 To create an fsfs repository, simply run 'svnadmin create
   --fs-type fsfs'.  Or, if BerkeleyDB wasn't detected at
@@ -187,7 +187,7 @@
 
 Bugfixes:
 More than 40 "small" bugs fixed.  See the http://svn.collab.net/repos/svn/trunk/CHANGES";>CHANGES file
+href="http://svn.apache.org/repos/asf/subversion/trunk/CHANGES";>CHANGES 
file
   for details.
 
 New subcommand switches:
@@ -243,7 +243,7 @@
 suffix, and the older versions are now marked deprecated (and will be
 removed in Subversion 2.0).  For example, a new svn_wc_diff2()
 function has superseded svn_wc_diff().  See the http://svn.collab.net/repos/svn/trunk/CHANGES";>CHANGES file
+href="http://svn.apache.org/repos/asf/subversion/trunk/CHANGES";>CHANGES 
file
 for details.
 
 There has been extensive work on the python, perl, and java
Index: publish/docs/release-notes/1.2.html
===
--- publish/docs/release-notes/1.2.html (revision 917589)
+++ publish/docs/release-notes/1.2.html (working copy)
@@ -138,7 +138,7 @@
 part of some other change pulled down via an OS package delivery
 mechanism — for example, upgrading one's Subversion
 package.  If this happens to you, you will need
-to upgrade existing BerkeleyDB-based
+to upgrade existing BerkeleyDB-based
 repositories to 4.3.
 
 In particular,
@@ -413,7 +413,7 @@
 title="Link to this section">¶
 
 More than 50 new bugs fixed.  See the http://svn.collab.net/repos/svn/trunk/CHANGES";>CHANGES file
+href="http://svn.apache.org/repos/asf/subversion/trunk/CHANGES";>CHANGES 
file
   for details.
 
 
@@ -436,7 +436,7 @@
 As with svn 1.1, a number of new 1.2 functions have been
 introduced, and older versions are now marked deprecated (and will be
 removed in Subversion 2.0).  See the http://svn.collab.net/repos/svn/trunk/CHANGES";>CHANGES file
+href="http://svn.apache.org/repos/asf/subversion/trunk/CHANGES";>CHANGES 
file
 for details.  The full list of new 1.2 APIs is http://svn.haxx.se/dev/archive-2005-04/0319.shtml";>here.
 
Index: publish/docs/release-notes/1.3.html
===
--- publish/docs/release-notes/1.3.html (revision 917589)
+++ publish/docs/release-notes/1.3.html (working copy)
@@ -338,7 +338,7 @@
 
 The "_svn" hack is
 now http://svn.collab.net/repos/svn/trunk/notes/asp-dot-net-hack.txt";>officially
+href="http://svn.apache.org/repos/asf/subversion/trunk/notes/asp-dot-net-hack.txt";>officially
 supported: since some versions of ASP.NET don't allow directories
 beginning with dot (e.g., ".svn", the standard Subversion working copy
 administrative directory), the svn command line client
@@ -415,7 +415,7 @@
 
 
 The usual slew of heretofore-unreleased bugfixes.  See the
-http://svn.collab.net/repos/svn/trunk/CHANGES";>CHANGES
+http://svn.apache.org/repos/asf/subversion/trunk/CHANGES";>CHANGES
 file for full details.
 
   

WIN32_RETRY_LOOP and opening read-only files for writing.

[Lieven Govaerts]

Hi,


I maintain some merge scripts written in Java that work with both
SVNKit and JavaHL. During unit testing on Windows XP we noticed that
some simple svn actions, like checkout take an extraordinary amount of
time. E.g. 'svn checkout' over ra_local of a branch with 3 folders and
6 100 bytes files takes appr. 20 seconds.

After some debugging we found that svn spends almost 15 seconds trying
to change a simple username file in ~\Subversion\auth\svn.username
(see attached extract of the Process Monitor log). It turns out this
file already existed and was set read-only. When JavaHL/svn creates
this file it makes it writeable, but SVNKit seems to create it as
read-only - which I suspect is a bug in SVNKit.

Looking at the Process Monitor output I suppose these 15 seconds are
spent in WIN32_RETRY_LOOP, defined in libsvn_subr/io.c.

WIN32_RETRY_LOOP tries in this case to open the file for writing, and
gets an ERROR_ACCESS_DENIED error. Now I know this error can mean lots
of things, so I don't propose to drop it altogether. But can't we add
a check that, if svn gets this error during file opening, it checks
first if the file is read-only before retrying 100 times?

I see we already do something similar in svn_io_remove_file.

Remarks?

Lieven


-
14:58:58,4206273javaw.exe   5976CreateFile  C:\Documents and
Settings\govaerl\Application
Data\Subversion\auth\svn.username\bfb50728e2262148ad4928381c7940bc  ACCESS
DENIED
Desired Access: Generic Write, Read Attributes, Disposition:
OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: 0
14:58:58,4207628javaw.exe   5976CreateFile  C:\Documents and
Settings\govaerl\Application Data\Subversion\auth\svn.username  SUCCESS
Desired Access: Synchronize, Disposition: Open, Options: Directory,
Synchronous IO Non-Alert, Open For Backup, Attributes: N, ShareMode:
Read, Write, AllocationSize: n/a, OpenResult: Opened
14:58:58,4212682javaw.exe   5976CloseFile   C:\Documents and
Settings\govaerl\Application Data\Subversion\auth\svn.username  SUCCESS

14:58:58,4268767javaw.exe   5976CreateFile  C:\Documents and
Settings\govaerl\Application
Data\Subversion\auth\svn.username\bfb50728e2262148ad4928381c7940bc  ACCESS
DENIED  Desired Access: Generic Write, Read Attributes, Disposition:
OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: 0
14:58:58,4270108javaw.exe   5976CreateFile  C:\Documents and
Settings\govaerl\Application
Data\Subversion\auth\svn.username   SUCCESS Desired Access: Synchronize,
Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open
For Backup, Attributes: N, ShareMode: Read, Write, AllocationSize:
n/a, OpenResult: Opened
14:58:58,4271387javaw.exe   5976CloseFile   C:\Documents and
Settings\govaerl\Application Data\Subversion\auth\svn.username  SUCCESS
...

Re: svnserve under Linux inetd hangs, burning CPU cycles, under too low TCP-sendbuffer.

[Philip Martin]

"Dr. Andreas Krüger"  writes:

>> I tried to reproduce your problem without using OpenVZ.
>
> thanks for trying! (Though I don't think you have succeeded.)

I suppose it might be an openvz-only bug.

> I'm not complaining about "slow". I'm complaining about "no progress
> at all" and "endless loop".

strace should show you whether or not the server is writing any data,
and whether or not the writes are failing.  Is it writing any data at
all?  Are the writes failing?

It would help if you could install a debug version of svnserve and
attach gdb to spinning process.

-- 
Philip

Re: svnserve under Linux inetd hangs, burning CPU cycles, under too low TCP-sendbuffer.

[Stefan Sperling]

On Mon, Mar 01, 2010 at 03:58:00PM +0100, "Dr. Andreas Krüger" wrote:
> So, as I said, this line of investigation lead nowhere.

Can you attach gdb to the spinning svnserve (with debug symbols)
and get a trace of where and how it's spinning?

Stefan

Re: [PATCH] 'svn patch' should remove empty dir

[Stefan Sperling]

On Sat, Feb 27, 2010 at 09:09:52PM +0100, Daniel Näslund wrote:
> Index: subversion/libsvn_client/patch.c
> ===
> --- subversion/libsvn_client/patch.c  (revision 916918)
> +++ subversion/libsvn_client/patch.c  (arbetskopia)
> @@ -34,6 +34,7 @@
>  #include "svn_path.h"
>  #include "svn_pools.h"
>  #include "svn_props.h"
> +#include "svn_sorts.h"
>  #include "svn_subst.h"
>  #include "svn_wc.h"
>  #include "client.h"
> @@ -1159,6 +1160,244 @@
>return SVN_NO_ERROR;
>  }
>  
> +/* Baton for find_existing_children() */
> +struct status_baton
> +{
> +  apr_array_header_t *existing_targets;
> +  const char *parent_path;
> +  apr_pool_t *result_pool;
> +};
> +
> +/* Implements svn_wc_status_func4_t. */
> +static svn_error_t *
> +find_existing_children(void *baton,
> +const char *abspath,
> +const svn_wc_status2_t *status,
> +apr_pool_t *pool)
> +{
> +  struct status_baton *btn = baton;
> +
> +  if (status->text_status != svn_wc_status_none
> +  && status->text_status != svn_wc_status_deleted
> +  && strcmp(abspath, btn->parent_path))
> +{
> +  APR_ARRAY_PUSH(btn->existing_targets, 
> + const char *) = apr_pstrdup(btn->result_pool,
> + abspath);
> +}
> +
> +  return SVN_NO_ERROR;
> +}
> +
> +/* Check if PARENT_DIR_ABSPATH has any versioned or unversioned children if
> + * we ignore the ones in TARGETS_TO_BE_DELETED. Return the answer in
> + * EMPTY. */
> +static svn_error_t *
> +is_dir_empty(svn_boolean_t *empty, const char *parent_dir_abspath,
> + svn_client_ctx_t *ctx, 
> + apr_array_header_t *targets_to_be_deleted,
> + apr_pool_t *result_pool, apr_pool_t *scratch_pool)
> +{
> +  struct status_baton btn;
> +  svn_opt_revision_t revision;
> +  int i;
> +
> +  btn.existing_targets = apr_array_make(scratch_pool, 0, 
> +sizeof(patch_target_t *));
> +  btn.parent_path = parent_dir_abspath;
> +  btn.result_pool = scratch_pool;
> +  revision.kind = svn_opt_revision_unspecified;
> +
> +  SVN_ERR(svn_client_status5(NULL, parent_dir_abspath, &revision,
> + find_existing_children, &btn, 
> + svn_depth_immediates, TRUE, FALSE, TRUE, 
> + FALSE, NULL, ctx, scratch_pool));

Not sure if svn_client_status5() is really what we want here.
Is there a public or semi-private libsvn_wc function we could
use instead? One that doesn't need a client context?

> +
> +  /* Do we delete all targets? */
> +  for (i = 0; i < btn.existing_targets->nelts; i++)
> +{
> +  int j;
> +  const char *found = APR_ARRAY_IDX(btn.existing_targets, i, const char 
> *);
> +  svn_boolean_t deleted = FALSE;
> +
> +  for (j = 0; j < targets_to_be_deleted->nelts; j++)
> +{
> +  patch_target_t *to_be_del;
> +  to_be_del = APR_ARRAY_IDX(targets_to_be_deleted, j, patch_target_t 
> *);
> +  if (! strcmp(found, to_be_del->abs_path))
> +deleted = TRUE;

Are you missing a 'break' here?

> +}
> +  if (! deleted)
> +{
> +  *empty = FALSE;
> +  break;
> +}
> +}
> +
> +  return SVN_NO_ERROR;
> +}
> +
> +/* Add TARGET to the array of targets keyed by their parent dir in
> + * TARGETS_TO_BE_DELETED. If there is no array for the parent dir a new one
> + * is created. All allocations are done in RESULT_POOL. */
> +static svn_error_t *
> +add_target_to_hash_keyed_by_parent_dir(apr_hash_t *targets_to_be_deleted, 
> +   patch_target_t *target,
> +   apr_pool_t *result_pool)
> +{
> +  apr_array_header_t * deleted_targets_in_dir;
> +
> +  /* We're using the abs_path of the target. The abs_path is not
> +   * present if the path is a symlink pointing outside the wc but we
> +   * know, that's not the case. */

The comma should either be removed, or moved: "... wc, but we know ...".

> +  const char *dirname = svn_dirent_dirname(target->abs_path, 
> +   result_pool);
> +
> +  deleted_targets_in_dir = apr_hash_get(targets_to_be_deleted, 
> +dirname, APR_HASH_KEY_STRING);
> +
> +  if (deleted_targets_in_dir)
> +{
> +  APR_ARRAY_PUSH(deleted_targets_in_dir, patch_target_t *) = target;
> +
> +  apr_hash_set(targets_to_be_deleted, dirname,
> +   APR_HASH_KEY_STRING, deleted_targets_in_dir);
> +}
> +  else
> +{
> +  apr_array_header_t *new_array;
> +
> +  new_array = apr_array_make(result_pool, 0, sizeof(patch_target_t *));
> +  APR_ARRAY_PUSH(new_array, patch_target_t *) = target;
> +  apr_hash_set(targets_to_be_deleted, 
> +   dirname, APR_HASH_KEY_STRING, new_array);
> +}
> +  return SVN

Re: svnserve under Linux inetd hangs, burning CPU cycles, under too low TCP-sendbuffer.

[Dr. Andreas Krüger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello, Philip,

> I tried to reproduce your problem without using OpenVZ.

thanks for trying! (Though I don't think you have succeeded.)

To follow your request, while the stuck download was running and
getting nowhere, I did two "ls -laR" on the client's working
directory. The crucial big-stupid-binary-file.bin.svn-base was at a
bit of 3 MB before the 20 seconds and at the same bit over 3 MB
afterwards, with not a byte of progress having been made in 20
seconds. Find the precise information at the end of this message.

The entire single 10 MB file checkout normally happens in about 7 seconds.

I'm not complaining about "slow". I'm complaining about "no progress
at all" and "endless loop".
 
Also, I tend to see no openvpn activity, so apparently no serious
amount of network traffic.

Just to rule out openvpn as a source of trouble, this time, I have
used an ssh tunnel. I set it up via

ssh -L :vzclientip: r...@vzhost

and used it via

cd /tmp; svn co localhost: bug

resulting in the buggy behavior. This was actually the setup I used
for those two ls -laR .

For the record: The SVN server is back to version 1.5.1 from Debian Lenny.

With the server still spinning, I can kill the svn client.

Mild "kill"s don't lead to any results. But, of course, "kill -9" does
the trick.

After that, I wait for another 20 seconds.

Even now, 20 seconds after the death of the partner (that is, almost
three times longer then the entire check out normally takes), the
svnserve is still at 99.something % CPU load. It continues to be there
until I kill the server.

So, imho, that's your "holy grail" to seek ;-) . That is, I speculate
if you can reproduce "99+% CPU load without client", you have indeed
reproduced my problem.

For the record: In a different experiment leading nowhere, I have
tried a few-line Perl script as a server, generating junk data. The
client, also a Perl script, actually double-checked it got the precise
junk the server had sent (as, of course, should be the case with
TCP/IP). Both were derived from what's in "man perlipc" under the
heading "Internet TCP Clients and Servers". Between those two, there
was no problem transferring 50 MB of data, even with ridiculously low
tcpsendbuf. I think 50k:350k is what I used at that time. So, as I
said, this line of investigation lead nowhere.

Regards,

Andreas

- --
Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH
andreas.krue...@dv-ratio.com
GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546  14C1 EA19 AADC FD44 5EB7

DV-RATIO NORDWEST GmbH
Tel: +49 (0)211 / 577 996-0
Fax: +49 (0)211 / 577 996-26
http://www.dv-ratio.com 
Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf
Registergericht Düsseldorf HRB 34330
USt-IdNr.:  DE811321837
Steuer-Nr.: 809/44031
Geschäftsführung: Günter Gerstmann
Prokura: Trudbert Vetter, Uwe Wolfram

DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980"




$ LANG=C sh -c 'ls -laR bug; sleep 20; echo again; ls -laR bug'
bug:
total 12
drwxr-xr-x  3 andreas andreas 4096 Mar  1 15:18 .
drwxrwxrwt 16 rootroot4096 Mar  1 15:20 ..
drwxr-xr-x  6 andreas andreas 4096 Mar  1 15:18 .svn

bug/.svn:
total 28
drwxr-xr-x 6 andreas andreas 4096 Mar  1 15:18 .
drwxr-xr-x 3 andreas andreas 4096 Mar  1 15:18 ..
- -r--r--r-- 1 andreas andreas  121 Mar  1 15:18 entries
- -rw-r--r-- 1 andreas andreas0 Mar  1 15:18 lock
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 prop-base
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 props
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 text-base
drwxr-xr-x 5 andreas andreas 4096 Mar  1 15:18 tmp

bug/.svn/prop-base:
total 8
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 .
drwxr-xr-x 6 andreas andreas 4096 Mar  1 15:18 ..

bug/.svn/props:
total 8
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 .
drwxr-xr-x 6 andreas andreas 4096 Mar  1 15:18 ..

bug/.svn/text-base:
total 8
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 .
drwxr-xr-x 6 andreas andreas 4096 Mar  1 15:18 ..

bug/.svn/tmp:
total 20
drwxr-xr-x 5 andreas andreas 4096 Mar  1 15:18 .
drwxr-xr-x 6 andreas andreas 4096 Mar  1 15:18 ..
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 prop-base
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 props
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 text-base

bug/.svn/tmp/prop-base:
total 8
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 .
drwxr-xr-x 5 andreas andreas 4096 Mar  1 15:18 ..

bug/.svn/tmp/props:
total 8
drwxr-xr-x 2 andreas andreas 4096 Mar  1 15:18 .
drwxr-xr-x 5 andreas andreas 4096 Mar  1 15:18 ..

bug/.svn/tmp/text-base:
total 3104
drwxr-xr-x 2 andreas andreas4096 Mar  1 15:18 .
drwxr-xr-x 5 andreas andreas4096 Mar  1 15:18 ..
- -rw-r--r-- 1 andreas andreas 3170304 Mar  1 15:18
big-stupid-binary-file.bin.svn-base
again
bug:
total 12
drwxr-xr-x  3 andreas andreas 4096 Mar  1 15:18 .
drwxrwxrwt 16 rootroot4096 Mar  1 15:20 ..
drwxr-xr-x  6 andreas andreas 4096 Mar  1 15:18 .svn

bug/.svn:
total 28
drwx

Re: Will subversion participate in Google Summer of Code 2010? - "merging XML or latex"

[Julian Foad]

Stefan Sperling wrote:
[...]
> > 2) Subversion should provide merge tools for dealing with xml or latex
> > ---
> > XML and LaTeX both is not purely linebased. One item may span multiple
> > rows and using the usual merge algorithm often (I say often, though I've
> > never tried to merge xml or latex files) gives us the wrong result.
> > Since atleast xml-files are very common I'm suspecting there is a use
> > case for a merge tool.
> 
> Subversion does not care about content.
> IMO This project should rather be about making an external merge tool
> that integrates nicely with svn.

A wide range of not-too-bad merge tools already exists.  We have some
basic support, and what we should be doing is making Subversion
integrate more nicely with them.  There's room for improvement in
several directions [1].  This group of enhancements needs a bit of
vision and planning before it's ready for a keen programmer to implement
it.

- Julian


[1] Off the top of my head: automatically invoke an appropriate merge
tool per content type (by user-defined rules or something); support for
merging properties as well as file content; easier customizing; ability
to merge files that Subversion currently thinks are "binary and
therefore not to be merged"; providing more informative file names to
the merge tool (rather than like "/tmp/temp123.tmp").

Re: Web-Site Bugs

[C. Michael Pilato]

Karl Heinz Marbaise wrote:
> Hi,
> 
> so the next thing.
> 
> Attached a patch for the publish/docs/release-notes/1.4.html file.

Committed your 1.6.patch, 1.5.patch, and this 1.4.patch in r917549.  Thanks,
Karl.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: Will subversion participate in Google Summer of Code 2010?

[Stefan Sperling]

On Sun, Feb 28, 2010 at 10:09:57PM +0100, Daniel Näslund wrote:
> 1) svn patch should use git diff format
> 

+1
I'd totally mentor this.

> 2) Subversion should provide merge tools for dealing with xml or latex
> ---
> XML and LaTeX both is not purely linebased. One item may span multiple
> rows and using the usual merge algorithm often (I say often, though I've
> never tried to merge xml or latex files) gives us the wrong result.
> Since atleast xml-files are very common I'm suspecting there is a use
> case for a merge tool.

Subversion does not care about content.
IMO This project should rather be about making an external merge tool
that integrates nicely with svn.

> 3) svn patch queues
> 
> Ok, maybe it needs a stable WC-NG but we're working hard on that and by
> summer there's a good chance we're there. I would really like to have
> this one.

+1 from me.
But I think Greg has ideas about offline commits which would make patch
queues superfluous. Also starting this with the current state of WC-NG
is probably a waste of time.

Stefan

Re: WC-NG - Doc strings and API design

[C. Michael Pilato]

Julian Foad wrote:
> We need doc strings.  We always do, but especially at this point we need
> them in order to assist other people in joining the effort to implement
> WC-NG.  I think one of the most useful things I can do at this point is
> help write them.
> 
> Doc strings go hand in hand with API design, as I'm sure we all know
> (subconsciously at least), so as I try to write them I am necessarily
> examining and trying to guess and then sometimes suggesting changes to
> the API design.  Sometimes that will be a separate step, sometimes part
> of the same patch.
> 
> Most of the APIs I'm looking at are private and sparsely documented, and
> 'wc_db.h' has a comment ending, '... do not want to doc until it feels
> like it is "Right"'.  It seems the time is now Right to consolidate,
> document, and change where better options are now apparent.  I don't
> want to step on anyone's toes or make gratuitous changes, so let me know
> if I seem to be doing so.
> 
> And I'm not going to do the whole API on my own.  I'll do some parts.
> Please step in and fix up another part of it if you can.

+1.  Or, +NUMBER_OF_API_FUNCTIONS.  This will be very useful to those of us
trying to crack open a can of WC-NG without spilling stuff all over the floor.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: Web-Site: Linking to CHANGES file for different releases

[C. Michael Pilato]

Neels J Hofmeyr wrote:
> Neels J Hofmeyr wrote:
>> Karl Heinz Marbaise wrote:
>>> Wouldn't it be better, based on historical reference to link to the
>>> CHANGES file into the appropriate release e.g.
>>>
>>> 1.1.html should reference .../repos/asf/subversion/tags/1.1.0/CHANGES
>>> 1.2.html should reference .../repos/asf/subversion/tags/1.2.0/CHANGES
>> (IOW make the 'CHANGES' link in site/publish/docs/release-notes/1.*.html
>> point at tags/1.*.0/CHANGES instead of trunk/CHANGES.)

[...]

> The trunk/CHANGES does include all versions' changes. Still, it would be
> good to not link to the collab.net repos anymore. (At least 1.1.html does 
> that.)

Yeah, the great thing about always pointing at trunk is that it contains all
the change records, so if you want to see what happened in other releases,
the info is readily available.

The bad thing is that it contains all the change records, so if you don't
want to see what happened in other releases, you gotta dig some for the
release you do care about.

But here's my case for *not* linking against the tagged CHANGES items:  we
only push out new release notes for big X.Y.0 releases, yet folks refer to
them as an explanation of what they are getting with any installation of
Subversion from the X.Y lineage.  It would be weird to download Subversion
1.6.9, read the 1.6 release notes, and then get pointed to a quite-stale
1.6.0 CHANGES list.  So if we're going to do anything around these parts, we
should be pointing to the CHANGES files as they exist in the release
*branches* (e.g. branches/1.6.x/CHANGES).

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: svnserve under Linux inetd hangs, burning CPU cycles, under too low TCP-sendbuffer.

[Philip Martin]

"Dr. Andreas Krüger"  writes:

> I also see
> several poll timeouts
>
> poll([{fd=0, events=POLLIN}], 1, 0) = 0 (Timeout)
>
> and several successful brk calls, before it finally all starts over again.
>
> More or less over again, that is. There seems to be an _llseek into
> that revision file that seeks differently each time. The precise
> numbers do not grow, they fluctuate.

I tried to reproduce your problem without using OpenVZ.  On my Linux
desktop I set:

  $ sudo sysctl -w net.ipv4.tcp_wmem='256 512 1024'

and then I used my laptop to checkout a working copy containing a 21MB
file.  It's very slow but it does succeed.  The client doesn't give
much feedback during a very slow checkout, but if you look in
.svn/tmp/text-base you can see the temporary text bases getting
bigger.

The svnserve process doesn't use much cpu, it's mostly waiting.  An
strace -T shows:

brk(0x17c7000)  = 0x17c7000 <0.15>
brk(0x17b7000)  = 0x17b7000 <0.29>
brk(0x17a7000)  = 0x17a7000 <0.20>
brk(0x17a5000)  = 0x17a5000 <0.13>
poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout) <0.10>
poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout) <0.09>
poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout) <0.09>
write(4, " ) ) ( textdelta-chunk ( 2:c1 9:\0"..., 4096) = 4096 <0.076367>
write(4, 
"S\371\266\370\321\364\3540+0\251\260m`\204\244\200\0210{>g:2\21I\343*\307foR\305"...,
 98422) = 98422 <2.678045>
read(6, 
"?\v\3\350+3p\264\210\3%\344g\3115\4a\203\247\301\31\227b\307\257ic\...@\177\35\230q"...,
 4096) = 4096 <0.18>

followed by several more reads and then it repeats.  As you can see
it's the second write call that takes a long time (2.7s), which isn't
really surprising since it's a big write with a small buffer.  If I
bump up the tcp_wmem values that time goes down to a tiny fraction of
a second.

> I finally increase this vz slice's tcpsndbuf allowance to
> 614400:921600 and, voila, that solves the problem.

Is there a bug here?  If you use small buffers the writes will be
slow.  Is the svnserve process using significant cpu or is it just
waiting for the writes to complete?  If you look in .svn/tmp/text-base
is the client making progress downloading the text bases?

-- 
Philip

WC-NG - Doc strings and API design

[Julian Foad]

We need doc strings.  We always do, but especially at this point we need
them in order to assist other people in joining the effort to implement
WC-NG.  I think one of the most useful things I can do at this point is
help write them.

Doc strings go hand in hand with API design, as I'm sure we all know
(subconsciously at least), so as I try to write them I am necessarily
examining and trying to guess and then sometimes suggesting changes to
the API design.  Sometimes that will be a separate step, sometimes part
of the same patch.

Most of the APIs I'm looking at are private and sparsely documented, and
'wc_db.h' has a comment ending, '... do not want to doc until it feels
like it is "Right"'.  It seems the time is now Right to consolidate,
document, and change where better options are now apparent.  I don't
want to step on anyone's toes or make gratuitous changes, so let me know
if I seem to be doing so.

And I'm not going to do the whole API on my own.  I'll do some parts.
Please step in and fix up another part of it if you can.
  
- Julian

[PATCH] WC-NG properties API - complete doc strings

[Julian Foad]

For review, please.  The patch below aims to provide complete doc
strings for (the existing implementation of) the WC-NG properties API.

I assume "properties" refers to regular, versioned properties
throughout.

I checked the implementation with regard to returning an error when the
node is not found.

I believe svn_wc__db_base_get_props() is meant to return an empty
(non-NULL) hash to represent "no properties", both because that's
consistent with the input and outputs of the rest of these functions and
because the rest of these functions never write "null" to the
"properties" column of the BASE table when writing an empty set of
properties.  The non-nullness of that SQL column is not (yet) documented
so I am not certain that there are no other functions that could write
"null". 

[[[
Provide complete doc strings for the WC-NG properties-storage API.

* subversion/libsvn_wc/wc_db.h
  (svn_wc__db_base_get_prop, svn_wc__db_base_get_props,
   svn_wc__db_op_set_props, svn_wc__db_temp_op_set_pristine_props,
   svn_wc__db_read_prop, svn_wc__db_read_props,
   svn_wc__db_read_pristine_props): Re-write doc strings.
--This line, and those below, will be ignored--

Index: subversion/libsvn_wc/wc_db.h
===
--- subversion/libsvn_wc/wc_db.h(revision 917441)
+++ subversion/libsvn_wc/wc_db.h(working copy)
@@ -646,14 +646,12 @@ svn_wc__db_base_get_info(svn_wc__db_stat
  apr_pool_t *scratch_pool);


-/** Return a property's value from a node in the BASE tree.
+/** Set *PROPVAL to the value of the property named PROPNAME of the node
+ * LOCAL_ABSPATH in the BASE tree.
  *
- * This is a convenience function to return a single property from the
- * BASE tree node indicated by LOCAL_ABSPATH. The property's name is
- * given in PROPNAME, and the value returned in PROPVAL.
- *
- * All returned data will be allocated in RESULT_POOL. All temporary
- * allocations will be made in SCRATCH_POOL.
+ * If the node has no property named PROPNAME, set *PROPVAL to NULL.
+ * If the node is not found in the BASE tree, return an error.
+ * Allocate *PROPVAL in RESULT_POOL.
  */
 svn_error_t *
 svn_wc__db_base_get_prop(const svn_string_t **propval,
@@ -664,14 +662,12 @@ svn_wc__db_base_get_prop(const svn_strin
  apr_pool_t *scratch_pool);


-/** Return all properties of the given BASE tree node.
+/** Set *PROPS to the properties of the node LOCAL_ABSPATH in the BASE tree.
  *
- * All of the properties for the node indicated by LOCAL_ABSPATH will be
- * returned in PROPS as a mapping of const char * names to
- * const svn_string_t * values.
- *
- * All returned data will be allocated in RESULT_POOL. All temporary
- * allocations will be made in SCRATCH_POOL.
+ * *PROPS maps "const char *" names to "const svn_string_t *" values.
+ * If the node has no properties, set *PROPS to an empty hash.
+ * If the node is not found in the BASE tree, return an error.
+ * Allocate *PROPS and its keys and values in RESULT_POOL.
  */
 svn_error_t *
 svn_wc__db_base_get_props(apr_hash_t **props,
@@ -952,21 +948,31 @@ svn_wc__db_op_add_symlink(svn_wc__db_t *
   apr_pool_t *scratch_pool);


-/* ### note: there is no db_op_set_prop() function. callers must read
-   ### all the properties, change one, and write all the properties.  */
-
-/* Set the props on the ACTUAL node for LOCAL_ABSPATH to PROPS.  This will
-   overwrite whatever working props the node currently has.  PROPS maps
-   property names of type "const char *" to values of type
-   "const svn_string_t *".  Use SCRATCH_POOL for temporary allocations. */
+/** Set the properties of the node LOCAL_ABSPATH in the ACTUAL tree to
+ * PROPS.
+ *
+ * This will overwrite whatever working properties the node currently has.
+ * Create an entry in the ACTUAL tree for the node if it is not there.
+ * PROPS maps "const char *" names to "const svn_string_t *" values.
+ * To specify no properties, PROPS must be an empty hash, not NULL.
+ *
+ * @note: There is no db_op_set_prop() function. Callers must read
+ * all the properties, change one, and write all the properties.
+ */
 svn_error_t *
 svn_wc__db_op_set_props(svn_wc__db_t *db,
 const char *local_abspath,
 apr_hash_t *props,
 apr_pool_t *scratch_pool);

-/* Sets the pristine props of LOCAL_ABSPATH on BASE, or when ON_WORKING is
-   TRUE on WORKING */
+/** Set the properties of the node LOCAL_ABSPATH in the BASE tree (if
+ * ON_WORKING is FALSE) or in the WORKING tree (if ON_WORKING is TRUE) to
+ * PROPS.
+ *
+ * PROPS maps "const char *" names to "const svn_string_t *" values.
+ * To specify no properties, PROPS must be an empty hash, not NULL.
+ * If the node is not found in the specified tree, return an error.
+ */
 svn_error_t *
 svn_wc__db_temp_op_set_pristine_props(svn_wc__db_t *db,
   const char *local_a

Re: [PATCH] 'svn patch' should remove empty dir

[Neels J Hofmeyr]

Julian Foad wrote:
> On Sat, 2010-02-27, Daniel Näslund wrote:
>> Reviews welcome!
>>
>> [[[
>> Make 'svn patch' able to remove dirs beeing empty after patching, taken
>> into account both versioned and unversioned files and dirs.
>>
>> * subversion/tests/cmdline/patch_tests.py
>>   (patch_remove_empty_dir): New.
>>   (test_list): Add new test.
>>
>> * subversion/libsvn_client/patch.c
>>   (status_baton): New.
>>   (find_existing_children, is_dir_empty,
>> add_target_to_hash_keyed_by_parent_dir, is_dir_empty,
>> sort_compare_nr_of_path_elements, 
>> maybe_condense_deleted_targets): New functions
>>   (apply_patches): Call maybe_condense_deleted_targets(). Check if a
>> target has a patch associated with it before calling
>> svn_diff__close_patch() since we're creating targets to delete dirs
>> and those have no associated patch.
>>
>> Patch by: Daniel Näslund 
>> Review by: julianf, stsp, neels
> 
> Huh? - - - - - ^^
> 
> Trying to twist my arm into reviewing it by posting a patch that says I
> have?  :-)

heh :)
AFAIR you have partaken in the review of a previous version of this patch.
Looking, I see that you have actually just commented a little...

http://mail-archives.apache.org/mod_mbox/subversion-dev/201002.mbox/%3c1266921402.4271.246.ca...@edith%3e

and

http://mail-archives.apache.org/mod_mbox/subversion-dev/201002.mbox/%3c1266841064.4271.146.ca...@edith%3e

How important is it to us to have 'Review by: ' crediting
anyway?

~Neels




signature.asc
Description: OpenPGP digital signature

Re: Web-Site Bugs

[Karl Heinz Marbaise]

Hi,

so the next thing.

Attached a patch for the publish/docs/release-notes/1.4.html file.


Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de
Index: publish/docs/release-notes/1.4.html
===
--- publish/docs/release-notes/1.4.html (revision 916999)
+++ publish/docs/release-notes/1.4.html (working copy)
@@ -129,7 +129,7 @@
 
 
 A new tool — http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt";
+href="http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt";
 >svnsync — is now installed as part of the standard
 distribution.  This tool provides the ability to replicate history
 from one repository to another.  The replication can happen all at
@@ -294,7 +294,7 @@
 allows svnserve to start automatically, at system boot time, without
 having a user logged in and without the need for an external service
 'wrapper' program. See http://svn.collab.net/repos/svn/tags/1.4.0/notes/windows-service.txt";>notes/windows-service.txt
+href="http://svn.apache.org/repos/asf/subversion/tags/1.4.0/notes/windows-service.txt";>notes/windows-service.txt
 for information on setting up svnserve as a Windows service.
 
   
@@ -337,7 +337,7 @@
 
 The usual slew of heretofore-unreleased bugfixes, more than 40
 overall. See the
-http://svn.collab.net/repos/svn/trunk/CHANGES";>CHANGES
+http://svn.apache.org/repos/asf/subversion/trunk/CHANGES";>CHANGES
 file for full details.
 
   

RE: Switch failure

[Bert Huijben]

> -Original Message-
> From: Михаил Кучма [mailto:proga1...@mail.ru]
> Sent: maandag 1 maart 2010 6:13
> To: dev@subversion.apache.org
> Subject: Switch failure
> 
> Good day.
> 
> Upon performing switch from branch to trunk I've got an error:
> 
> In file D:\Development\SVN\Releases\TortoiseSVN-
> 1.6.2\ext\subversion\subversion\libsvn_ra_svn\marshal.c
> line 486: assertion failed (opt || cstr)

This case was most likely fixed in Subversion 1.6.6, so the most current
version (1.6.9) should resolve this and other issues for you.

Thanks,
Bert