> -----Original Message-----
> From: dglasser@gmail.com [mailto:dglasser@gmail.com] On
> Behalf Of David Glasser
> Sent: Tuesday, December 18, 2007 1:29 PM
> To: dev
> Subject: mergeinfo terminology
>
> 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)
I know we use (a) in svn_client__merge_path_t, but where do we use (c)?
> (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;
No bikeshedding from me, that all sounds perfectly reasonable.
Paul
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 19 03:48:32 2007