On Sun, Jul 02, 2006 at 06:43:49AM -0500, Ben Collins-Sussman wrote:
> >(Oh, and how _do_ you find out
> >programmatically what changelist (changelists?) are associated with a
> >given path - ah, svn_client_info?)
>
> A path can only be associated with one changelist. To find out
> programmatically, just look at entry->changelist. To find out as a
> user, use 'svn info' to look at the entry. (Or use 'svn status' to
> see the whole changelist.)
>
Yeah, I figured that out as I kept reading, but it might be a good idea
to xref the programmatic way in the doc-comments (though I've not re-read
them - they may be clearer now). Certainly, providing a set_changelist()
function without a get_changelist() equivalent is odd enough that I'd
expect some kind of explanation.
> >
> >Do we need a new version of svn_client_info() that guarantees to call
> >the receiver with a version of the svn_info_t structure that includes
> >'changelist'? Or do we assume that if the caller wants to access that
> >member, they should be clever enough to check that the current runtime
> >library version is >= 1.5? (via, I guess, something like
> >svn_subr_version()).
>
> I'm not aware of any applications that check the version of
> libsvn_client at runtime. Typically a new version of the application
> is released, and it simply *requires* libsvn_cllient 1.5 at
> compile-time, end of story. My impression is that the only time apps
> need to start worrying about run-time version checks are for loaded RA
> modules, where it really is possible to stumble across an old library
> during dlopen().
>
> So I think that even though svn_info_t is a public, transparent
> structure, I've done the usual recommended practice of just adding a
> new field to the end of it. Isn't that how we've always done things
> for non-RA structures?
>
Thinking about it some more, yes, I think what we currently have is fine.
The only reason I was a little worried is because unlike the normal
situation - where the new symbols won't exist in the old library - it's
perfectly possible to run a compiled-with-1.5 caller of svn_client_info
on a 1.4 library, and the only difference is that the ->changelist member
is complete junk.
But I don't think the potential for an uncautious developer making this
mistake is worth revving the API - there isn't really any way to make
it clearer other than writing "This field of the structure will be junk
in pre-1.5 clients", and that seem to me to be over the top.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 3 16:29:26 2006