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

mergeinfo terminology

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-18 19:28:42 CET

Writing code that uses mergeinfo is very confusing. This is because
there are several types floating around that represent mergeinfo:

(a) a string representation of a single target's mergeinfo (as svn_string_t *)

(b) a hash representation of a single target's mergeinfo (as a hash
  mapping (const char *) to array of (svn_merge_range_t *)

(c) a hash mapping target paths (const char *) to (a)

(d) a hash mapping target paths (const char *) to (b)

I think at the very least we need to come up with consistent
terminology for referring to these things. I suggest:

(a) "unparsed mergeinfo"

(b) "mergeinfo" (or "parsed mergeinfo" to be explicit)

(c) "unparsed mergeinfo catalog" (but we perhaps should avoid this
    type in general)

(d) "mergeinfo catalog"

Additionally, I think we should consider making typedefs for (b) and (d):

typedef apr_hash_t *svn_mergeinfo_t;
typedef apr_hash_t *svn_mergeinfo_catalog_t;

While these typedefs won't provide any extra static type-checking (if
we really wanted that, we could write custom wrappers around
apt_hash_{get,set,count,first,make,etc}), that's no regression from
the present situation, and it would help humans.

Bikeshed away.

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 18 19:28:54 2007

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.