Issue 2732 (was Unhandled exception when stopping apache)

On 3/24/07, D.J. Heap <djheap <at> gmail.com> wrote:
[snip]
>
> Thanks, it looks good.  It appears to be a shutdown/cleanup ordering
> problem in the bdb stuff after a quick first glance.  I know there was
> a lot of pain and work on that issue a while ago -- should be fun to
> figure out.  I'll try to work on it as soon as I can but it's not very
> high on my list at the moment.

I've been debugging this and narrowed it down quite a bit.  I'm
puzzled how it works on other OS' at all, though, so I think I'm
mis-understanding something.

In libsvn_fs_base\bdb\env.c the bdb_init_cb function allocates the bdb
cache stuff in the global pool (I think?) and registers a cleanup
callback to clear_cache.

Then in final process termination (after unloading modules) when
Apache cleans out the global pool
(apr\memory\unix\apr_pools.c:apr_pool_terminate), it tries to call the
clear_cache function -- but it's already been unloaded by then and so
goes boom.

Am I mis-understanding the sequence of things or does it work
differently on unixy OS'?

The crash goes away if I comment out the clear_cache cleanup registration.

DJ

Re: Improved patch format - SoC

> Just wanted to throw out the idea that allowing comments in the patch
> file might be useful for enabling both justification for individual
> code changes and suggestions for improvement if a patch was being
> passed back and forth. If comments were supported in the format then
> there would be the potential for integration with merge GUIs etc.

It's an interesting idea. In SVK generating a patch is like commiting. 
Including in a patch format a place for adding a patch description (a 
changelog entry, bah) sounds like a nice idea. That patch description 
could be used in a future commits of that patch. I like it.

Re: Subversion win32 crash with neon 0.26.x over https/SPNEGO

On 3/30/07, Martin Yves <yves.martin <at> elca.ch> wrote:
>
>
>  Hello,
>
> My Subversion compilation on win32 platform was successful.
> A first test with 1.4.x branch and neon 0.25.5 works properly
> (I mean: SPNEGO authentication works if the URL contains the server
> fully qualified name)
>
> When building with neon 0.26.x, the svn command line crash with a null
> pointer (yes I'm a Java guy) in libsvn_ra_dav/util.c:
>

Have you tried with neon's HEAD version?  I seem to recall some auth
related fixes that haven't been in a release yet (r1161 looks like it
may be relevant).

DJ

Re: How to generate text deltas for cvs2svn using the Python bindings?

On 3/31/07, Michael Haggerty <mhagger <at> alum.mit.edu> wrote:

> Suppose I have two versions of a file (for example, in Python strings or
> file-like objects) and I want to generate the text delta between them in
> a form that I can stick in an svndump file.  Can I do this using the
> Python SVN bindings?
>
> Example code would be very welcome.

Off the top of my head, I think you just need to create an
svn_stream_t for each of the files, and then create a 'txdelta stream'
from them... that is, a stream from which you pull 'txdelta' windows
(of svndiff data) and push them at a window consumer routine
(presumably one you write, which dumps the data to a dumpfile.)

I'm not entirely sure if svn_delta.h has been swigged into python, but
that's probably the API you want.  Take a look at how svn_repos_dump()
works in libsvn_repos -- see how it generates svndiff data into the
dumpfile.

Here's a document I wrote in ancient days that might help.  Brush off the dust:

    http://svn.collab.net/repos/svn/trunk/notes/txdelta_sanity

Re: Adding --depth support to the status command

Lieven Govaerts <lgo <at> mobsol.be> writes:
> "The -N option becomes a synonym for --depth=files for these commands.
>        * checkout
>        * switch
>        * update
>        * status
>        * info "
>
> First of all, info doesn't accept -N, so unless there's a reason I don't
> know about, we can remove that from this list.

But 'info' does accept -R (and currently --depth), because it is
non-recursive by default.

> Second, the current behavior of status -N is to show the status of both
> files and directories in the target. In 'depth' terms, this is the
> equivalent of --depth=immediates.
>
> So should I map status -N to 'status --depth=immediates' to match the
> current  behavior? Or to 'status --depth=files' to make it consistent
> over all commands?
>
> Given -N is now obsolete, I prefer to just match current behavior and
> get rid of that flag asap. Anyone who disagrees?

I think your proposal makes sense.  The empty immediate subdir in a
--depth=immediates checkout still has a .svn dir, and a this-dir entry
in its entries file, so we can talk about its status.

FWIW, here's the patch I was working on before we merged.  It doesn't

Re: Issue 2732 (was Unhandled exception when stopping apache)

D.J. Heap wrote:
> On 3/24/07, D.J. Heap <djheap <at> gmail.com> wrote:
> [snip]
>>
>> Thanks, it looks good.  It appears to be a shutdown/cleanup ordering
>> problem in the bdb stuff after a quick first glance.  I know there was
>> a lot of pain and work on that issue a while ago -- should be fun to
>> figure out.  I'll try to work on it as soon as I can but it's not very
>> high on my list at the moment.
>
>
> I've been debugging this and narrowed it down quite a bit.  I'm
> puzzled how it works on other OS' at all, though, so I think I'm
> mis-understanding something.
>
> In libsvn_fs_base\bdb\env.c the bdb_init_cb function allocates the bdb
> cache stuff in the global pool (I think?) and registers a cleanup
> callback to clear_cache.
>
> Then in final process termination (after unloading modules) when
> Apache cleans out the global pool
> (apr\memory\unix\apr_pools.c:apr_pool_terminate), it tries to call the
> clear_cache function -- but it's already been unloaded by then and so
> goes boom.
>
> Am I mis-understanding the sequence of things or does it work
> differently on unixy OS'?
>
> The crash goes away if I comment out the clear_cache cleanup registration.

Re: Improved patch format - SoC

Nicolás Lichtmaier wrote:
> == Introduction ==
>
> The diff/patch tools have been great tools. The format they use
> (called "unified diff")

Correction: "unified diff" is in fact a later addition to the set of
diff formats (the original diff didn't have it), and is by no means
universally accepted as "the standard". IIRC the GCC project, for
example, insists that patshes be submitted in context-diff, not
unified-diff format. Reading man diff(3) will give you a list of
different formats that diff can output, and consequently patch can accept.

An improved diff format that aims to be(come) compatible with patch
should be applicable to at least the original plain diff, context-diff
and unified-diff; possible even ed-script diff (see diff -e), though I
suspect that one looses too much context to be useful for patches.

[...]

> Just as Subversion took the best of CVS concepts and created a better
> version control system, we should take this format and enhance it so
> that it can serve Subversion needs.  Those new needs are three:
>
> * The ability of describe tree modifications (renames, deletions, etc.),

This is more complicated than it looks, if you insist on compatibility
with current diff/patch. Diff is file-based, whereas tree modifications
are not.

svn_wc_relocation_validator3_t's documentation needs update?

Hi,

svn_wc_relocation_validator3_t's document says:

 ...
 * If  <at> a root is true, then the implementation should make sure that  <at> a url
 * is the repository root.  Else, it can be an URL inside the repository.
 *  <at> a pool may be used for temporary allocations.
 ...

But

  typedef svn_error_t *(*svn_wc_relocation_validator3_t)(void *baton,
                                                         const char *uuid,
                                                         const char *url,
                                                         const char *root_url,
                                                         apr_pool_t *pool);

doesn't include "root" parameter. Is
svn_wc_relocation_validator3_t's documentation old?

Thanks,
--
kou

Re: Improved patch format - SoC

> Correction: "unified diff" is in fact a later addition to the set of
> diff formats (the original diff didn't have it), and is by no means
> universally accepted as "the standard". IIRC the GCC project, for
> example, insists that patshes be submitted in context-diff, not
> unified-diff format. Reading man diff(3) will give you a list of
> different formats that diff can output, and consequently patch can accept.
>   

I know that. But is "unified diff" the format that is clearly widely 
preferred. IMO it's the one that should be used as inspiration for the 
new format.

> An improved diff format that aims to be(come) compatible with patch
> should be applicable to at least the original plain diff, context-diff
> and unified-diff; possible even ed-script diff (see diff -e), though I
> suspect that one looses too much context to be useful for patches.
>
> [...]
>
>   
>> Just as Subversion took the best of CVS concepts and created a better
>> version control system, we should take this format and enhance it so
>> that it can serve Subversion needs.  Those new needs are three:
>>
>> * The ability of describe tree modifications (renames, deletions, etc.),
>>     
>
> This is more complicated than it looks, if you insist on compatibility
> with current diff/patch. Diff is file-based, whereas tree modifications

[PATCH] svn_wc_relocate3() should have ' <at> since New in 1.5'

Hi,

{{{
* subversion/include/svn_wc.h (svn_wc_relocate3):
  Add missing  <at> since markup.
}}}

Thanks,
--
kou

Index: subversion/include/svn_wc.h
===================================================================
--- subversion/include/svn_wc.h	(revision 24303)
+++ subversion/include/svn_wc.h	(working copy)
 <at>  <at>  -3606,6 +3606,8  <at>  <at> 
  *
  *  <at> a adm_access is an access baton for the directory containing
  *  <at> a path.
+ *
+ *  <at> since New in 1.5.
  */
 svn_error_t *
 svn_wc_relocate3(const char *path,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe <at> subversion.tigris.org