You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2004/11/14 20:30:06 UTC
Review 1.2 API changes
Since API changes can get us in a bit of a mess if we are not careful, I would
like to review the changes that we are going to make for version 1.2.
I will give a summary of the changes, grouped by type of change, and then we
can consider and discuss the changes in each group. There is one additional
issue on which I include notes, and that is the desire to change from Boolean
"recurse" to integer "depth" arguments.
Grep "@since.*1\.2" (Does anyone have a quick way to find API changes without
relying on the "@since" comment having been added?)
+/-/=/! means added/deleted/same/different. My comments are in parentheses.
# Add peg revision.
svn_client_blame2
+ const svn_opt_revision_t *peg_revision
svn_client_propget2
+ const svn_opt_revision_t *peg_revision
= svn_boolean_t recurse
(Not all callers changed)
svn_client_proplist2
+ const svn_opt_revision_t *peg_revision
= svn_boolean_t recurse
svn_client_export3
+ svn_opt_revision_t *peg_revision
(Not const?)
(No recurse option.)
(Not all callers changed from svn_client_export.)
svn_client_ls2
+ svn_opt_revision_t *peg_revision
(Not const?)
= svn_boolean_t recurse
(tools/examples/minimal_client.c not updated.)
svn_client_cat2
+ const svn_opt_revision_t *peg_revision
(Existing comment: ### TODO: Add an expansion/translation flag?)
# Miscellaneous.
svn_opt_args_to_target_array2
- svn_opt_revision_t *start_revision,
- svn_opt_revision_t *end_revision,
- svn_boolean_t extract_revisions,
svn_client_move2
- const svn_opt_revision_t *src_revision
svn_errno_t
+ SVN_ERR_WC_INVALID_SCHEDULE "Invalid schedule"
("@since" comment is not a Doxygen comment.)
svn_wc_adm_open_anchor
(New function.)
# Allow setting of a property value that the client considers invalid.
svn_client_propset2
+ svn_boolean_t force
= svn_boolean_t recurse,
svn_wc_prop_set2
+ svn_boolean_t force
# Diff prop changes with dir/file changes.
svn_wc_diff_callbacks2_t
(Big change.)
svn_wc_get_diff_editor3
! const svn_wc_diff_callbacks2_t *callbacks
= svn_boolean_t recurse
svn_wc_diff3
! const svn_wc_diff_callbacks2_t *callbacks
= svn_boolean_t recurse
# New "limit" argument for "log" command.
svn_client_log2
+ unsigned int limit
svn_ra_plugin_t
+ get_log2 (with "limit", as in svn_client_log2)
(This is added to the end of the existing structure.)
(Do we need to document what to set 'get_log' and 'get_log2' to? Should one
of them be NULL, or both be usable functions?)
svn_repos_get_logs3
+ unsigned int limit
(Previous version doesn't document the difference.)
svn_ra_dav__get_log2
(Undocumented.)
(Private, so doesn't need "@since"?)
svn_ra_local__get_log2
(Undocumented.)
(Private, static, so doesn't need "@since"?)
ra_svn_log2
(Undocumented.)
(Private, static, so doesn't need "@since"?)
All of these replace an older version and mark it as deprecated, except
svn_wc_adm_open_anchor which is new, svn_errno_t::SVN_ERR_WC_INVALID_SCHEDULE
which is a new constant added compatibly to its enum, and
svn_ra_plugin_t::get_log2 which is a new member added compatibly to its struct.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - miscellaneous
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> # Miscellaneous.
I did the first two of these, so of course I approve of them, and I don't know
about the other two. Any comments?
- Julian
> svn_opt_args_to_target_array2
> - svn_opt_revision_t *start_revision,
> - svn_opt_revision_t *end_revision,
> - svn_boolean_t extract_revisions,
>
> svn_client_move2
> - const svn_opt_revision_t *src_revision
>
> svn_errno_t
> + SVN_ERR_WC_INVALID_SCHEDULE "Invalid schedule"
> ("@since" comment is not a Doxygen comment.)
>
> svn_wc_adm_open_anchor
> (New function.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> # Allow setting of a property value that the client considers invalid.
This seems fine. (It was issue #2065.)
- Julian
> svn_client_propset2
> + svn_boolean_t force
> = svn_boolean_t recurse,
>
> svn_wc_prop_set2
> + svn_boolean_t force
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - "bool recurse" vs. "int depth"
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> There is
> one additional issue on which I include notes, and that is the desire to
> change from Boolean "recurse" to integer "depth" arguments.
I was thinking that whenever we are changing a function's signature, maybe we
should take the opportunity to change "bool recurse" to "int depth", even if
the function does not yet implement depths other than (1 or 0) and infinity.
Or, more probably, we should change all of the APIs that currently take "bool
recurse".
The only benefit I can see is that a client can then be built that supports a
UI for specifying depth, and it will be able to run with this 1.2 API (failing
at run-time for certain depth arguments) and won't have to be upgraded as and
when we do make these library functions support other depths.
I don't feel strongly about this. Do you think that is worth doing? Can you
see any other pros or cons?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> $ svn diff http://svn.collab.net/repos/svn/tags/1.1.0/subversion/include \
> http://svn.collab.net/repos/svn/trunk/subversion/include
Thanks. These additional changes show up:
> Index: svn_ra_svn.h
> ===================================================================
> +/** A value used to indicate an optional number element in a tuple that was
> + * not received.
> + */
> +#define SVN_RA_SVN_UNSPECIFIED_NUMBER ~((apr_uint64_t) 0)
svn_client_get_commit_log_t:
Document that "apr_array_header_t *commit_items" is read-only.
svn_client_log -> svn_client_log2:
> - * @a targets contains all the working copy paths (as <tt>const char
> - * *</tt>'s) for which log messages are desired. The repository info is
> + * @a targets contains either a URL followed by zero or more relative
> + * paths, or a list of working copy paths (as <tt> const char *</tt>'s
> + * for which log messages are desired. The repository info is
> * determined by taking the common prefix of the target entries' URLs.
> * @a receiver is invoked only on messages whose revisions involved a
> * change to some path in @a targets.
> *
> - * ### todo: the above paragraph is not fully implemented yet.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Grep "@since.*1\.2" (Does anyone have a quick way to find API changes
> without relying on the "@since" comment having been added?)
$ svn diff http://svn.collab.net/repos/svn/tags/1.1.0/subversion/include \
http://svn.collab.net/repos/svn/trunk/subversion/include
You'll get some useless info there, but the result is easier to parse
and more complete than grepping.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - log --limit
Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> > * We really, really should not use "unsigned" in the interface. I
> > recommend reverting r11162 which converted various arguments to
> > unsigned.
>
> I disagree. If passing a negative value makes no sense semantically,
> then the parameter should be unsigned.
Heheh. Do we have any desire to support a negative limit to mean,
"show me all but the last N revisions" ?
/me runs. Fast.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - log --limit
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Looking back, it strikes me that
> limit should be an svn_revnum_t, because it represents the same range of
> values.
It should not be an "svn_revnum_t", because "Number of revisions" is not the
same concept as "Revision number". It would be reasonable to argue that
"limit" should be an integer big enough to hold the values of "svn_revnum_t"
(which is not the case at the moment) so that one can request any desired
amount of the whole log history. On the other hand it would be reasonable to
argue that "limit" does _not_ have to cover that range because while revision
numbers might become huge, the number of revisions involved in any given log
history request will generally remain much smaller than the total number of
revisions in the repository, and it is unlikely to be practically useful to
request a huge yet limited log.
> So... I'm withdrawing my objection. Let's change the thing to signed,
Reverted r11162 in r11909. I hope that wasn't rude ... maybe I should have
waited for Garrett Rooney's approval, as he made the original commit. Garrett,
I hope you don't mind.
> and by all means fix that atoi.
Certainly it would be nice to fix it, but that's "only" an implementation bug.
I'm concentrating on the API at the moment.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - log --limit
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> So, do you see any of these signed/unsigned mismatch warnings from a
> Subversion build on Win32?
Some, a few not in our code. Mostly I see narrowing warnings, e.g.,
apr_off_t to apr_size_t (64->32 bits on Win32), which I've not yet
figured out how to fix cleanly (they're mostly in the diff code and will
only bother someone who has text files larger that 4G, so they aren't
very high on my priority list...).
> How many?
I don't recall at this moment, I don't have a build box handy.
> Do they include this assignment introduced by r11162 in
> subversion/mod_dav_svn/log.c line 244?
> unsigned int limit;
> limit = atoi(child->first_cdata.first->text);
Ah, but in this case, we're converting from int to unsigned int, which
in C, is a standard integer promotion and I'd be very surprised if any
compiler warned about it.
However, there's a more fundamental bug in that line, namely the use of
atoi. atoi("fubar") will happily return 0, and should therefore never be
used to parse program options. We should use strtol here, check that it
converted the whole string, check that the result is nonnegative (or
positive, --limit=0 is a bit weird) and is less than UINT_MAX, then we
can safely cast it.
> "gcc -W" catches signed/unsigned comparisons, of which we have three
> "unsigned >= 0" tautologies and no variable/variable mismatches
> (except for one which I introduced recently in a test file and will
> fix by changing the local variable to unsigned int).
>
> "gcc -Wconversion" catches signed/unsigned conversions as well as
> other conversions (e.g. width). We currently trigger 240 in total,
> 106 width changes and 134 signed/unsigned conversions.
>
> I haven't found an option that generates warnings for mismatched
> assignments, like that "limit = atoi()".
Quite as expected.
> We have to work with the limitations of the language we use. Unsigned
> integers are great for low-level work, but not for high-level C
> interfaces.
The fact that C has unsigned integers is not a limitation of the
language. What does happen quite often is that people unthinkingly use
(witness that atoi) or design broken APIs that fail to take conversion
edge cases into account. Notice that even changing the limit paramter to
a signed int won't fix the bug in the atoi usage.
However, you make a good case with listing precedents, two of which
(svn_config_enumerate, svn_txdelta_window_t) and one you did not mention
(svn_filesize_t) I wrote myself... Looking back, it strikes me that
limit should be an svn_revnum_t, because it represents the same range of
values.
So... I'm withdrawing my objection. Let's change the thing to signed,
and by all means fix that atoi.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - log --limit
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Julian Foad wrote:
>> * We really, really should not use "unsigned" in the interface. I
>> recommend reverting r11162 which converted various arguments to unsigned.
>
> I disagree. If passing a negative value makes no sense semantically,
> then the parameter should be unsigned.
The semantics argument is good in principle, but unfortunately in the C
language the risks outweigh the benefits. If signed/unsigned conversions were
strongly checked, then I would agree with you.
John Lakos makes a compelling case in his book "Large Scale C++ Software
Design" (as I mentioned in http://svn.haxx.se/dev/archive-2004-10/0075.shtml).
Also, the Java language designers dropped the idea of unsigned integers, and
made all integers signed, and I believe that their experience with C had a lot
to do with it.
And there is no precedent in our public interfaces. The only places where we
use "unsigned" are "unsigned char". On the other hand, we frequently use plain
"int" for things that are semantically non-negative:
* retry_limit in svn_client_get_simple_prompt_provider (and similar functions).
* Return value of svn_config_enumerate (etc.) (the number of times the callback
was called).
* svn_txdelta_window_t::num_ops/src_ops (number of instructions in this window).
* svn_revnum_t (the excuse of wanting to use -1 as a special value could apply
to "limit" as well).
* etc.
>> Just now I tried "svn log --limit=-5" and it listed all revisions.
>
> Then this is a bug in parsing the value of that option. The parser
> should reject negative values.
Certainly. I agree. I suppose r11162 wasn't intended to fix that, in which
case it was unfair of me to reason as if it was.
>> r11162 did not solve that problem, and indeed it introduced
>> signed/unsigned mismatches. Compilers can warn about signed/unsigned
>> mismatches, but they are a necessary evil in many places so the
>> potential to be warned about them isn't often an actual benefit.
>
> I disagree with this, too. signed/unsigned mismatches can and should be
> avoided by careful attention to detail in the implementation. When there
That r11162 was made and has continued to exist, yet contains such mismatches,
is testament to the fact that, while they can in principle be detected and
avoided, in practice they are not being detected and avoided.
> is absolutely no other possible fix (due to defects in other libraries,
> not bugs in Subversion), then usually it's possible to find a safe way
> to cast the value, and document the reason for the cast.
Yes, certainly.
> So I'd suggest that, in maintainer mode, we turn on these warnings where
> possible. Note that they're already on by default on Win32.
So, do you see any of these signed/unsigned mismatch warnings from a Subversion
build on Win32? How many? Do they include this assignment introduced by
r11162 in subversion/mod_dav_svn/log.c line 244?
unsigned int limit;
limit = atoi(child->first_cdata.first->text);
"gcc -W" catches signed/unsigned comparisons, of which we have three "unsigned
>= 0" tautologies and no variable/variable mismatches (except for one which I
introduced recently in a test file and will fix by changing the local variable
to unsigned int).
"gcc -Wconversion" catches signed/unsigned conversions as well as other
conversions (e.g. width). We currently trigger 240 in total, 106 width changes
and 134 signed/unsigned conversions.
I haven't found an option that generates warnings for mismatched assignments,
like that "limit = atoi()".
We have to work with the limitations of the language we use. Unsigned integers
are great for low-level work, but not for high-level C interfaces.
- Julian
(For GCC users: "gcc -W" gives other types of warning that are not relevant to
us; one such type that contributes many messages can be switched off by adding
"-Wno-unused-parameter".)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - log --limit
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Julian Foad wrote:
>
>> # New "limit" argument for "log" command.
>
>
> This seems fine except for two things:
>
> * We really, really should not use "unsigned" in the interface. I
> recommend reverting r11162 which converted various arguments to unsigned.
I disagree. If passing a negative value makes no sense semantically,
then the parameter should be unsigned.
> Just now I tried "svn log --limit=-5" and it listed all revisions.
Then this is a bug in parsing the value of that option. The parser
should reject negative values.
> r11162 did not solve that problem, and indeed it introduced
> signed/unsigned mismatches. Compilers can warn about signed/unsigned
> mismatches, but they are a necessary evil in many places so the
> potential to be warned about them isn't often an actual benefit.
I disagree with this, too. signed/unsigned mismatches can and should be
avoided by careful attention to detail in the implementation. When there
is absolutely no other possible fix (due to defects in other libraries,
not bugs in Subversion), then usually it's possible to find a safe way
to cast the value, and document the reason for the cast.
So I'd suggest that, in maintainer mode, we turn on these warnings where
possible. Note that they're already on by default on Win32.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - log --limit
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> # New "limit" argument for "log" command.
This seems fine except for two things:
* We really, really should not use "unsigned" in the interface. I recommend
reverting r11162 which converted various arguments to unsigned.
Just now I tried "svn log --limit=-5" and it listed all revisions. r11162 did
not solve that problem, and indeed it introduced signed/unsigned mismatches.
Compilers can warn about signed/unsigned mismatches, but they are a necessary
evil in many places so the potential to be warned about them isn't often an
actual benefit.
* A few small documentation issues, as noted below.
- Julian
> svn_client_log2
> + unsigned int limit
>
> svn_ra_plugin_t
> + get_log2 (with "limit", as in svn_client_log2)
> (This is added to the end of the existing structure.)
> (Do we need to document what to set 'get_log' and 'get_log2' to?
> Should one of them be NULL, or both be usable functions?)
I think it would be worth stating what the requirement is in that regard.
>
> svn_repos_get_logs3
> + unsigned int limit
> (Previous version doesn't document the difference.)
We normally say in the deprecated version's doc string, "Same as [new version]
except [whatever is different]".
>
> svn_ra_dav__get_log2
> (Undocumented.)
> (Private, so doesn't need "@since"?)
>
> svn_ra_local__get_log2
> (Undocumented.)
> (Private, static, so doesn't need "@since"?)
>
> ra_svn_log2
> (Undocumented.)
> (Private, static, so doesn't need "@since"?)
These last three probably don't need any doc string, as they can easily be
traced to svn_ra_plugin_t::get_log2.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - add peg revision
Posted by Josh Pieper <jj...@pobox.com>.
Julian Foad wrote:
> Julian Foad wrote:
> ># Add peg revision.
>
> Josh Pieper, this is your area. Are you willing to make the changes below?
I am willing, and think the changes are good. However my time is
still somewhat limited, so the changes will come in slowly.
-Josh
> I also may have some concerns about the choosing of default values in these
> new APIs, and the command-line interface for peg revisions, but I will
> raise those separately.
>
> >
> >svn_client_blame2
> > + const svn_opt_revision_t *peg_revision
> >
> >svn_client_propget2
> > + const svn_opt_revision_t *peg_revision
> > = svn_boolean_t recurse
> > (Not all callers changed)
>
> All callers should use the new version, as it would be rude to expect other
> people to stop using the deprecated function if we continue to use it
> ourselves.
>
> >svn_client_proplist2
> > + const svn_opt_revision_t *peg_revision
> > = svn_boolean_t recurse
> >
> >svn_client_export3
> > + svn_opt_revision_t *peg_revision
> > (Not const?)
>
> Add "const" (unless there is a good reason not to).
>
> > (No recurse option.)
> > (Not all callers changed from svn_client_export.)
>
> Change the callers.
>
> >
> >svn_client_ls2
> > + svn_opt_revision_t *peg_revision
> > (Not const?)
>
> Add "const".
>
> > = svn_boolean_t recurse
> > (tools/examples/minimal_client.c not updated.)
>
> Not essential, but it would be really good to update that example.
>
> >
> >svn_client_cat2
> > + const svn_opt_revision_t *peg_revision
> > (Existing comment: ### TODO: Add an expansion/translation flag?)
>
> There's no urgent need to address this TODO right now, as it isn't part of
> the change from 1.1 to 1.2, but it would be nice to decide whether we are
> going to do it and not have the "###" comment in the code.
>
> - Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes - add peg revision
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> # Add peg revision.
Josh Pieper, this is your area. Are you willing to make the changes below?
I also may have some concerns about the choosing of default values in these new
APIs, and the command-line interface for peg revisions, but I will raise those
separately.
>
> svn_client_blame2
> + const svn_opt_revision_t *peg_revision
>
> svn_client_propget2
> + const svn_opt_revision_t *peg_revision
> = svn_boolean_t recurse
> (Not all callers changed)
All callers should use the new version, as it would be rude to expect other
people to stop using the deprecated function if we continue to use it ourselves.
> svn_client_proplist2
> + const svn_opt_revision_t *peg_revision
> = svn_boolean_t recurse
>
> svn_client_export3
> + svn_opt_revision_t *peg_revision
> (Not const?)
Add "const" (unless there is a good reason not to).
> (No recurse option.)
> (Not all callers changed from svn_client_export.)
Change the callers.
>
> svn_client_ls2
> + svn_opt_revision_t *peg_revision
> (Not const?)
Add "const".
> = svn_boolean_t recurse
> (tools/examples/minimal_client.c not updated.)
Not essential, but it would be really good to update that example.
>
> svn_client_cat2
> + const svn_opt_revision_t *peg_revision
> (Existing comment: ### TODO: Add an expansion/translation flag?)
There's no urgent need to address this TODO right now, as it isn't part of the
change from 1.1 to 1.2, but it would be nice to decide whether we are going to
do it and not have the "###" comment in the code.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> Is there any chance I could get the keywords-as-hash code added to the
> 1.2 release? The reason I ask is that there are a couple of signature
> changes (specifically the one I mentioned above) which will require
> another compatibility layer if it is implemented later, and it seems
> silly to have svn_subst_copy_and_translate3() if we don't have to.
Since we've not yet branched for 1.2, and will wait at least for the
locking implementation before we do, I'd say there's time enough. Modulo
the quality of the patches, of course. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes
Posted by John Peacock <jp...@rowman.com>.
Julian Foad wrote:
>
> That was added in 1.1 - we can't change it now. It has "@since".
Excellent! I go away for a few months and work on a new e-mail server and I
completely miss the boat on this. I didn't notice that the special file
handling was a 1.1 addition and that it had already changed that signature.
[insert appropriate swearword for your locale].
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes
Posted by Julian Foad <ju...@btopenworld.com>.
John Peacock wrote:
> You missed the changes to svn_subst_copy_and_translate2() which support
> the special file handling. As Brane (I believe) suggested, a diff
> between the trunk and the last release is probably better than grep'ing
> (though it would be nice to go back and make sure that the appropriate
> @since was added).
That was added in 1.1 - we can't change it now. It has "@since".
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Review 1.2 API changes
Posted by John Peacock <jp...@rowman.com>.
Julian Foad wrote:
> Grep "@since.*1\.2" (Does anyone have a quick way to find API changes
> without relying on the "@since" comment having been added?)
You missed the changes to svn_subst_copy_and_translate2() which support the
special file handling. As Brane (I believe) suggested, a diff between the trunk
and the last release is probably better than grep'ing (though it would be nice
to go back and make sure that the appropriate @since was added).
This brings up a point I was hoping to broach soon anyways:
Is there any chance I could get the keywords-as-hash code added to the 1.2
release? The reason I ask is that there are a couple of signature changes
(specifically the one I mentioned above) which will require another
compatibility layer if it is implemented later, and it seems silly to have
svn_subst_copy_and_translate3() if we don't have to.
The codebase has wandered quite far from where it was when I submitted my last
patches, but I have some time this week (I'm on medical leave) to bring them up
to date. I'm going to withdraw the third part (which allowed for custom
keywords from properties) until such time as I can get a good proposal for
inherited properties written up (that may also be something I can do this week)
and, more importantly, agreed upon as a way to proceed.
I'm pitching the keywords-as-hash concept as currently a way to future proof the
code; it becomes much easier to add new aliases and keywords in the future if we
aren't dealing with a struct any longer.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org