RE: svn commit: r35330 - trunk/subversion/include

> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: woensdag 21 januari 2009 9:42
> To: dev_at_subversion.tigris.org
> Subject: Re: svn commit: r35330 - trunk/subversion/include
>
> Hrm. What happens if third-party code creates one of these hashes, and
> only puts an svn_log_changed_path_t in there? (rather than path2)

I thought about this (revving the api/field was the actual suggestion
referenced below).

But to have a problem there would have to be third party code that creates
svn_log_entry_t instances for fourth party code..

If that third and fourth assume the same api level, there is no problem (As
they both expect new or old).. Only when they expect different api levels we
(or they) would have a real problem.

One possible solution would be to add an extra field with the new hash type
and just use the same apr_hash_t value. (And document that to be the case),
but that would break those same clients (unless they build fallback code),
as they would expect the second field to be filled..

Revving the entire log api would be another option...

We should have declared the structure future extensible from the start to
make sure we don't get these issues... (like I did with
svn_log_changed_path2_t now)

        Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1040774
Received on 2009-01-21 11:11:53 CET