mark benedetto king | 1 Oct 04:35 2006

Re: [PATCH] [libsvn_ra_svn/client.c] confugre remote command for tunnel via $SVN_REMCMD instead hardcoded svnserve

On Tue, Sep 19, 2006 at 11:08:28AM +0200, Stefan Petri wrote:
> Hi!
> 
> I have stumbled across several cases where access via tunneling failed 
> because the remote svnserve binary was not in a system default search 
> path. The subversion FAQ and manual show the workaround via tweaking ssh 
> key configuration, but I have several cases where that is not 
> applicable. So, here is 4-line patch , which takes the command to invoke 
> from the environment variable SVN_REMCMD. If that is not set, the remote 
> command defaults to "svnserve".
> Enjoy,
>                                                      Stefan
> 
> [[[
> subversion/libsvn_ra_svn/client.c use SVN_REMCMD to override hardcoded 
> "svnserve"
> 
> To circumvent problems with the hardcoded invocation of "svnserve" on 
> the remote end of tunnels, look for environment variable SVN_REMCMD.
> Fall back to "svnserve" if that is not set.
> This helps when e.g. the svnserve command is not in the remote systems 
> default search path, and ssh key trickery as descibed in the Subversion 
> manual is not applicable.
> ]]]
> 

Why not make SVN_SSH point to a shell script that replaces the "svnserve"
parameter with something else?

--ben
(Continue reading)

Erik Huelsmann | 1 Oct 11:06 2006
Picon

Re: svn trunk r21723: FAIL (x86-macosx-gnu shared ra_local fsfs)

On 9/30/06, buildbot <at> mobsol.be <buildbot <at> mobsol.be> wrote:
> Full details are available at:
> http://www.mobsol.be/buildbot/x86-macosx-gnu%2520shared%2520ra_local%2520fsfs/builds/1136
>
> Author list: dionisos

It turns out that special_tests 7 (merge link into file) creates a
broken symlink, so that the link could be stat()ed, but the file can't
be opened for reading (not that it makes sense to do so with a
symlink).

bye,

Erik.
Lieven Govaerts | 1 Oct 11:13 2006
Picon

Re: svn trunk r21723: FAIL (x86-macosx-gnu shared ra_local fsfs)

Erik Huelsmann wrote:
> On 9/30/06, buildbot <at> mobsol.be <buildbot <at> mobsol.be> wrote:
>> Full details are available at:
>>
http://www.mobsol.be/buildbot/x86-macosx-gnu%2520shared%2520ra_local%2520fsfs/builds/1136 
>>
>>
>> Author list: dionisos
>
> It turns out that special_tests 7 (merge link into file) creates a
> broken symlink, so that the link could be stat()ed, but the file can't
> be opened for reading (not that it makes sense to do so with a
> symlink).
Hm, we need more info.

What's incorrect about the symlink?

Do we need to fix the test to create a correct symlink? Or should the 
code be changed to not open symlinks for reading?

Lieven.
Erik Huelsmann | 1 Oct 11:16 2006
Picon

Re: svn trunk r21723: FAIL (x86-macosx-gnu shared ra_local fsfs)

On 10/1/06, Lieven Govaerts <svnlgo <at> mobsol.be> wrote:
> Erik Huelsmann wrote:
> > On 9/30/06, buildbot <at> mobsol.be <buildbot <at> mobsol.be> wrote:
> >> Full details are available at:
> >> http://www.mobsol.be/buildbot/x86-macosx-gnu%2520shared%2520ra_local%2520fsfs/builds/1136
> >>
> >>
> >> Author list: dionisos
> >
> > It turns out that special_tests 7 (merge link into file) creates a
> > broken symlink, so that the link could be stat()ed, but the file can't
> > be opened for reading (not that it makes sense to do so with a
> > symlink).
> Hm, we need more info.
>
> What's incorrect about the symlink?
>
> Do we need to fix the test to create a correct symlink? Or should the
> code be changed to not open symlinks for reading?

See r21725 :-)

But, we may need tests with broken and valid symlinks which create
both categories on purpose. I think this test wasn't creating the
brokenness on purpose.

bye,

Erik.
(Continue reading)

Barry Scott | 1 Oct 13:16 2006

Re: Request: expose the peg algorithm at the svn API level


On Sep 30, 2006, at 15:57, Barry Scott wrote:

>
> alternative would be to have _peg versions of a lot more commands.  
> svn_client_cat_peg,
> svn_client_info_peg etc.

Opss, I should have researched better, you have already implemented  
this everywhere.

Barry
David Glasser | 1 Oct 19:53 2006
Picon

Re: svn propedit URL

On 9/30/06, David Glasser <glasser <at> mit.edu> wrote:
> So, either: how do I refer to svn_stream_t in svn_props.h, or what
> design simplification am I totally missing?

OK, I ended up just making this a WC api (since it needs to call
svn_wc_parse_externals_description2 anyway).  Attached is a patch to
create an API for validating and canonicalizing svn:* props.  This
will then be usable by svn_client_propset3 for checking properties
that are being set on URLs.

I think this patch is kind of ugly, but necessary to achieve this
functionality.  I would appreciate eyes before committing it.

--dave

--

-- 
David Glasser | glasser <at> mit.edu | http://www.davidglasser.net/
=== subversion/include/svn_wc.h
==================================================================
--- subversion/include/svn_wc.h	(revision 21716)
+++ subversion/include/svn_wc.h	(patch - level 1)
 <at>  <at>  -2907,8 +2907,53  <at>  <at> 
 /** Return true iff  <at> a name is a 'entry' property name. */
 svn_boolean_t svn_wc_is_entry_prop(const char *name);

+/** Callback type used by  <at> c svn_wc_canonicalize_svn_prop.
+ *  
+ * It should set  <at> a mime_type to the value of  <at> a SVN_PROP_MIME_TYPE
(Continue reading)

David Glasser | 1 Oct 20:05 2006
Picon

[PATCH] Re: svn propedit URL

On 10/1/06, David Glasser <glasser <at> mit.edu> wrote:
> I think this patch is kind of ugly, but necessary to achieve this
> functionality.  I would appreciate eyes before committing it.

Oops, and here's the log message:

[[[
Extract the validation and canonicalization of svn:* properties from
svn_wc_prop_set2 into a new API, which could theoretically be used
for "svn propset URL".

* subversion/include/svn_wc.h
  (svn_wc_canonicalize_svn_prop): New API to validate and canonicalize
   svn:* properties.
  (svn_wc_canonicalize_svn_prop_get_file_t): New callback type for above API.

* subversion/libsvn_wc/props.c
  (svn_wc_canonicalize_svn_prop): Implement new API (extracted from
   svn_wc_prop_set2).
  (getter_baton): New baton implementation for new callback.
  (get_file_for_validation): New function, implementing new callback
type; contents
   extracted from validate_eol_prop_against_file.
  (validate_eol_prop_against_file): Use callback instead of direct WC access.
  (svn_wc_prop_set2): Use new API for property validation and canonicalization
   instead of doing it directly.
  (validate_prop_against_node_kind, validate_eol_prop_against_file,
   svn_wc_parse_externals_description2): Allow an argument which is
only used in error
   messages to be an URL.
(Continue reading)

David Glasser | 1 Oct 21:21 2006
Picon

Re: svn commit: r21728 - in trunk/subversion: include libsvn_wc

On 10/1/06, dionisos <at> tigris.org <dionisos <at> tigris.org> wrote:
> Author: dionisos
> Date: Sun Oct  1 11:45:44 2006
> New Revision: 21728
>
> Log:
> Make room for 31 more svn_wc_entry_t fields to be manipulated by resizing
> the flags bitmap to 63 bits.
>
> Note: APR 0.9 has no APR_UINT64_C, meaning we can only define
>       constants for the first 63 bits.
>
> Note: I need at least 1 more svn_wc_entry_t field to store
>       the revertbase checksum.
>
> * subversion/libsvn_wc/relocate.c
> * subversion/libsvn_wc/entries.c
> * subversion/libsvn_wc/copy.c
> * subversion/libsvn_wc/entries.h
> * subversion/libsvn_wc/log.c
> * subversion/libsvn_wc/adm_ops.c
> * subversion/libsvn_wc/log.h
> * subversion/libsvn_wc/update_editor.c
>   Change the flags bitfield from apr_uint32_t to apr_uint64_t.
>
>
>
> Modified:
>    trunk/subversion/include/svn_wc.h

(Continue reading)

Erik Huelsmann | 1 Oct 21:52 2006
Picon

Re: svn commit: r21728 - in trunk/subversion: include libsvn_wc

On 10/1/06, David Glasser <glasser <at> mit.edu> wrote:
> On 10/1/06, dionisos <at> tigris.org <dionisos <at> tigris.org> wrote:
> > Author: dionisos
> > Date: Sun Oct  1 11:45:44 2006
> > New Revision: 21728
> >
> > Log:
> > Make room for 31 more svn_wc_entry_t fields to be manipulated by resizing
> > the flags bitmap to 63 bits.
> >
> > Note: APR 0.9 has no APR_UINT64_C, meaning we can only define
> >       constants for the first 63 bits.
> >
> > Note: I need at least 1 more svn_wc_entry_t field to store
> >       the revertbase checksum.
> >
> > * subversion/libsvn_wc/relocate.c
> > * subversion/libsvn_wc/entries.c
> > * subversion/libsvn_wc/copy.c
> > * subversion/libsvn_wc/entries.h
> > * subversion/libsvn_wc/log.c
> > * subversion/libsvn_wc/adm_ops.c
> > * subversion/libsvn_wc/log.h
> > * subversion/libsvn_wc/update_editor.c
> >   Change the flags bitfield from apr_uint32_t to apr_uint64_t.
> >
> > Modified:
> >    trunk/subversion/include/svn_wc.h
>
> The log message is missing the change to include/svn_wc.h.
(Continue reading)

Lieven Govaerts | 1 Oct 22:42 2006
Picon

Re: svn trunk r21729: FAIL (i686-debian-sarge1 shared gcc-3.3.5)

buildbot <at> mobsol.be wrote:
> Full details are available at: 
> http://www.mobsol.be/buildbot/i686-debian-sarge1%2520shared%2520gcc-3.3.5/builds/514
> 
> Author list: dionisos
> 
> Build Slave: eh-debsarge1
> 
> 
> Subversion Buildbot
> http://www.mobsol.be/buildbot/

Hi,

attached patch will fix this build failure (on all platforms).

Apparently what happened was erik included a change in r21728 which 
wasn't supposed to be committed yet. In r21729 part of that change was 
rolled back (declaration of a struct member) but that field was used 
which made the build fail.

Attached patch will revert the rest of that change.

Lieven.

[[[
*subversion/libsvn_wc/entries.c: revert a piece of code that was 
accidentally committed in r21728.
]]]
(Continue reading)


Gmane