On Thu, 2005-05-12 at 13:37, Peter N. Lundblad wrote:
> Hi,
>
> >From your questions below, it seems like you need read the HACKING
> document. It explains some of the concepts in more detail.
I will do that. thanks.
>
> On Wed, 11 May 2005, Madan US wrote:
>
> > On Tue, 2005-05-10 at 06:53, Philip Martin wrote:
> > > "Madan US" <madan@collab.net> writes:
> > >
> > > That's an ABI change in a public interface so it's not acceptable.
> > > You need to retain svn_commit_callback_t and provide a new name,
> > > svn_commit_callback2_t say, with the new parameter.
> > Whats ABI? I think all functions, pointers that comply to
> > svn_commit_callback_t have been touched in this patch. However, I
> > understand the client-server version compatibility issue. Is this your
> > concern. Could you please explain your concern with an illustration ( a
> > scenario ) so that I can make changes with an inherent understanding...
> > this would also be a learning for me. Thanks.
>
> ABI means Application Binary INterface. It includes things as function
> calling conventions (in what order arguments are put on the stack, where
> the return value is placed etc.) and other things that ensures binary
> compatibility. When *we* talk about ABI breakage we mean that code linked
> to one version of the library will not work with a later version. Adding
> (or removing or changing) the arguments to a function is obviously an ABI
> change; it will make the program crash or something similar. Changing the
> contents of a structure is often an ABI change (some might argue it always
> does). Read more about our compatibility rules in HACKING.
okay. I understand.
>
>
> > >
> > > Unfortunately this looks like it could be quite a big change. You
> > > need to keep all the current interfaces that use svn_commit_callback_t
> > > and ensure that they continue to work. Then you can provide new
> > > versions of those interfaces that support the new callback.\
> > Yes, all functions adhering to and using this typedef will be changed,
> > but we would be keeping the old versions nevertheless.... that IMHO
> > would be inefficient. Pl. comment.
>
> Well, it is not fun, if that's what you're referring to... I've done some
> API revving, so I know:-)
>
> But remember that we're a library. Other applications are using our code,
> and we can't just force them to upgrade every time we release new stuff.
Yes, I agree... this looks obvious once someone tells me :-) ... I'm working
on this... hope to send in a patch bytonite...
thanks for your patient explanation. It really helps. :-)
>
>
> > > I'm not a DAV/XML expert, can you put arbitrary data there? Do you
> > > have to encode it, or escape it?
> > >
> > > Hmm, a quick experiment shows that the existing hook output appears to
> > > get escaped over ra_dav, but not encoded. The hook needs to output
> > > UTF-8 if it is to be displayed by the client, otherwise I just see
> > > "svn: General svn error from server".
> > yes, I missed this point... the output of the post-commit hook should be
> > encoded to utf-8. Anyways, I do not know how to do this... will try to
> > find out... thanks for that.
> > >
>
> More importantly (for the moment) is that it needs to be XML-escpaed, that
> means replacing some characters with XML entities (< becomes < and so
> on). See apr_xml_quote_string. (See my comment in my response regarding
> encodings and invalid XML chars).
mmm... I will look into this. thanks for the pointer.
>
> Regards,
> //Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 12 11:07:40 2005