[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

mergeinfo API cleanup: questions

From: David Glasser <glasser_at_davidglasser.net>
Date: Thu, 14 Feb 2008 12:06:34 -0800

I'm working on cleaning up the mergeinfo API. The key parts are
establishing the concepts of svn_mergeinfo_t and
svn_mergeinfo_catalog_t, and discouraging using any other data type
(other than svn_string_t) to pass the data around through public APIs.
 This lets us get rid of the dozens of docstrings saying "@a mergeinfo
is a hash mapping const char * keys starting with slashes to hashes
mapping const char * keys starting with slashes to apr_array_header_t
*s containing svn_merge_range_t *s sorted in ascending order", for
example.

I'm doing this on the mergeinfo-api-cleanup branch.

Here are some questions remaining for me:

* svn_rangelist_reverse and svn_mergeinfo_sort both trouble me: they
  imply that it's ever valid to pass around unsorted rangelists.
  svn_mergeinfo_sort is easy enough to privatize, but I have to admit
  I don't actually understand the point of svn_rangelist_reverse.
  It's used in essentially two places, in some rollback-related range
  math. Is there some higher-level operation describing what's being
  done there which we could replace svn_rangelist_reverse with, and
  never expose "backwards" range lists outside of
  libsvn_subr/mergeinfo.c?

* svn_rangelist_count_revs, svn_rangelist_to_revs, and
  svn_range_compact are never used outside of the test suite. Do we
  need them? I guess the first two might hypothetically be useful to
  other clients. What about svn_range_compact?

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-14 21:06:47 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.