[PATCH] Document the fix for link errors with libneon on AMD64 Linux systems.

This has come up a couple of times recently on users <at> .

[[[
Document the fix for link errors with libneon on AMD64 Linux systems.

www/faq.html (relocation-against-local-symbol): New entry.
]]]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe <at> subversion.tigris.org
For additional commands, e-mail: dev-help <at> subversion.tigris.org

Re: [PATCH] commit-email.pl: support subject line based on log message

On Mon, Mar 31, 2008 at 3:52 PM, Blair Zajac <blair <at> orcaware.com> wrote:
>
> David Glasser wrote:
>  > 2008/3/28 Gregory Nathan Price <price <at> mit.edu>:
>  >> This adds to commit-email.pl a flag --summary,
>  >>  which produces subject lines like
>  >>   r123 - Stop frobbing the veeblenitzer
>  >>  instead of the familiar
>  >>   r123 - in src/veeble: . nitzed
>  >>  , copying the first line of the log message into the subject line.
>  >>
>  >>  [[[
>  >>  * tools/hook-scripts/commit-email.pl.in
>  >>   Support --summary for taking subject line from log message.
>  >>
>  >>  Patch by: Greg Price <price <at> mit.edu>
>  >>  ]]]
>  >>
>  >>  I've generally preferred this form of subject line in the small
>  >>  projects I've worked on, and would be very pleased to get it with
>  >>  a flag rather than patching commit-email.pl every time.
>  >
>  > Looks reasonable to me.  However, instead of:
>  >
>  >     chop(my $summary = $log[0]);
>  >
>  > how about
>  >
>  >     my $summary =  <at> log ? $log[0] : '';
>  >     chop $summary;

Re: [PATCH] serf backend requires servers category configuration

Hi,

2008/4/1, Lieven Govaerts <svnlgo <at> mobsol.be>:
> Silly question: what does svn do without your patch? Does it crash?
>  Ignore configuration?

I don't know about svn but a Ruby script showed in
http://svn.haxx.se/dev/archive-2008-03/0933.shtml
is crashed.

> $ cat svn_test.rb
> require 'svn/ra'
> context = Svn::Client::Context.new
> callbacks = Svn::Ra::Callbacks.new(context.auth_baton)
> session = Svn::Ra::Session.open("http://localhost/", {}, callbacks)
> session.commit_editor2("commit log") {}

Thanks,
--
kou

>  Kouhei Sutou wrote:
>  > Hi,
>  >
>  > I found a difference between Neon backend and Serf backend.
>  >
>  > Neon backend doesn't require SVN_CONFIG_CATEGORY_SERVERS
>  > configuration but Serf backend does.
>  >
>  > Index: subversion/libsvn_ra_serf/serf.c

Re: [PATCH] commit-email.pl: support subject line based on log message

David Glasser wrote:
> On Mon, Mar 31, 2008 at 3:52 PM, Blair Zajac <blair <at> orcaware.com> wrote:
>> David Glasser wrote:
>>  > 2008/3/28 Gregory Nathan Price <price <at> mit.edu>:
>>  >> This adds to commit-email.pl a flag --summary,
>>  >>  which produces subject lines like
>>  >>   r123 - Stop frobbing the veeblenitzer
>>  >>  instead of the familiar
>>  >>   r123 - in src/veeble: . nitzed
>>  >>  , copying the first line of the log message into the subject line.
>>  >>
>>  >>  [[[
>>  >>  * tools/hook-scripts/commit-email.pl.in
>>  >>   Support --summary for taking subject line from log message.
>>  >>
>>  >>  Patch by: Greg Price <price <at> mit.edu>
>>  >>  ]]]
>>  >>
>>  >>  I've generally preferred this form of subject line in the small
>>  >>  projects I've worked on, and would be very pleased to get it with
>>  >>  a flag rather than patching commit-email.pl every time.
>>  >
>>  > Looks reasonable to me.  However, instead of:
>>  >
>>  >     chop(my $summary = $log[0]);
>>  >
>>  > how about
>>  >
>>  >     my $summary =  <at> log ? $log[0] : '';
>>  >     chop $summary;

1.5 Neon bug in copy-on-update

Here's today's episode of "Subversion WebDAV RA tries to be too smart
for its own good instead of just serializing RA API calls like
ra_svn"!

Before 1.5, server never sent add-with-history to clients, so it would
never make sense for a "remove prop" XML element to be inside an "add
file" element.

And in fact, libsvn_ra_neon/fetch.c(validate_element) tries to
validate this, throwing a corrupted XML error if (among many other
things) an ELEM_remove_prop is inside an ELEM_add_file.  This breaks
the update.  (Similar issues presumably include remove-prop inside
add-directory, and delete-entry inside add-directory, but perhaps many
more combinations as well.)

To reproduce, do something like:

 $ svn ps foo bar a
 $ svn ci
 Revision 10.
 $ svn cp a b
 $ svn pd foo b
 $ svn ci
 Revision 11.
 $ svn up -r10
 $ svn up -r11

I have no idea if serf has this bug; I've just verified that ra_svn
and ra_local don't.

Re: svn_cache review

r30148, r31049, and r30150 address your concerns from this thread,
except for the const void * one, which I'm looking into now.

--dave

On Tue, Mar 25, 2008 at 5:08 PM, Eric Gillespie <epg <at> google.com> wrote:
> > Index: subversion/libsvn_fs_fs/tree.c
>  > ===================================================================
>
>  >  /* Invalidate cache entries for PATH and any of its children. */
>  > -static void
>  > +static svn_error_t *
>  >  dag_node_cache_invalidate(svn_fs_root_t *root,
>  > -                          const char *path)
>  > +                          const char *path,
>  > +                          apr_pool_t *pool)
>  >  {
>  > -  fs_txn_root_data_t *frd;
>  > -  apr_size_t len = strlen(path);
>  > -  const char *key;
>  > -  dag_node_cache_t *item;
>  > +  struct fdic_baton b;
>  > +  svn_cache_t *cache;
>  > +  int i;
>  >
>  > +  b.path = path;
>  > +  b.pool = svn_pool_create(pool);
>  > +  b.list = apr_array_make(b.pool, 1, sizeof(const char *));
>  > +
>  >    assert(root->is_txn_root);

Re: Re-merge a change from own history - corrupts svn:mergeinfo

On Mon, Mar 31, 2008 at 4:04 PM, Julian Foad <julianfoad <at> btopenworld.com> wrote:
> The following merge corrupts svn:mergeinfo:
>
>  svn merge --ignore-ancestry --accept=mine-full -c26169 \
>    subversion/tests/cmdline/merge_tests.py \
>
>    subversion/tests/cmdline/merge_tests.py
>
>  because (in subversion/libsvn_client/merge.c) do_file_merge() says:
>
>    if (honor_mergeinfo)
>      {
>        ...
>        calculate mergeinfo_path
>        ...
>      }
>    ...
>    if (record_mergeinfo ...)
>      {
>        ...
>        use mergeinfo_path
>        ...
>      }
>
>  and, in merges like this one, "record_mergeinfo" is true but "honor_mergeinfo"
>  isn't.
>
>  One interpretation of the bug is to say that we should never be recording
>  mergeinfo when we're not honouring it, because we decided that we never would
>  want to and that "ignore_ancestry" should prevent both things. In that case,

Re: Re-merge a change from own history - corrupts svn:mergeinfo

On Mon, Mar 31, 2008 at 9:50 PM, Paul Burba <ptburba <at> gmail.com> wrote:

>  I agree that we need to clarify the effect --ignore-ancestry has
>  regarding mergeinfo.  Your fix is certainly correct in that it fixes
>  the bogus mergeinfo/segfault, but I'm not sure that it is correct in
>  terms of expanding the meaning of --ignore-ancestry to mean *not*
>  setting mergeinfo.  To get back to what Karl said earlier in this
>  thread, maybe we need a --no-record option so we can do all of the
>  following:
>
>  A) Ignore mergeinfo when calculating what to merge and don't set any mergeinfo
>
>  B) Ignore mergeinfo when calculating what to merge but set mergeinfo
>  describing the merge
>
>  C) Consider mergeinfo when calculating what to merge but don't set any mergeinfo
>
>  D) Consider mergeinfo when calculating what to merge and set mergeinfo
>  describing the merge
>
>  Question is, are there valid use cases for all of these?  Obviously
>  there is for D, that's Merge Tracking(TM)!  B is what using
>  --ignore-ancestry today does and it seems potentially useful in cases
>  like those described in issue #2898 - Imagine a case like that
>  described in http://subversion.tigris.org/issues/show_bug.cgi?id=2898#desc7
>  where there are other subtrees with mergeinfo that we want
>  updated/elided.
>
>  But for A and C I can't come up with a valid use case...Given that B
>  and D are handled today, for 1.5 I'd be happy just fixing

Re: RFC: svn mergeinfo improvements for 1.5

On Fri, Mar 28, 2008 at 2:15 PM, Julian Foad <julianfoad <at> btopenworld.com> wrote:
> C. Michael Pilato wrote:
>  > Mark Phippard wrote:
>  >
>  >> I agree with you in principle, but Dan and I have been thinking and
>  >> talking about this since last summer.  I think if you really stop and
>  >> think about it, it is obvious that log output is what someone wants
>  >> here.  In my opinion, a list of revisions is useless.  What script
>  >> would that possibly drive?  If you are just going to feed them back
>  >> into a merge command, then that is a fairly useless script.  svn merge
>  >> will already do this for you automatically by just omitting the
>  >> revision argument.  Maybe you know you only want revisions over 1000
>  >> for some reason.  OK, again, svn merge -r1000:HEAD will do this
>  >> automatically.
>  >>
>  >> People are going to want to run this command so they can make informed
>  >> decisions about what to merge.  Such as "have we nominated everything
>  >> for backport into 1.5 that needs to be".  To answer those questions,
>  >> you want a filtered log.  It does not make sense to have the command
>  >> already have all that information and just discard it when we know
>  >> that is what people want.
>
>  To answer that question, people want a lot of high-level information. This
>  command can begin to give them that information, but it can't in general give
>  them all the high-level information they will ever need.
>
>  (Of course the system has lots of interesting information inside it, but that
>  doesn't mean we should print it all out to avoid "wasting" it. I'm sure you
>  didn't mean for that to sound the way it sounded.)
>

RE: depth of the operation vs. depth of the WC

Hi dave,
Of course I would like to contribute a patch. But I'm not very sure about
some details of my statement yet, especially about how the depth of
operation works. I may need to check the source code to confirm about this.
I'll present a patch later when I'm confident enough. ^_^
Rui, Guo
> 
> You have some useful points here; care to submit patches to the
documentation?
> 
> --dave