Re: branch tc_url_rev: almost ready to merge

Quoting Julian Foad <julianfoad_at_btopenworld.com>:

> On Mon, 2008-11-24 at 16:05 +0100, Stefan Sperling wrote:
>> On Mon, Nov 24, 2008 at 12:23:26PM +0000, Julian Foad wrote:
>> > On Mon, 2008-11-24 at 07:02 +0100, Neels J Hofmeyr wrote:

> [...]
>> > > + /* Remember to update svn_wc__conflict_version_dup()
>> > > + * in case you add fields to this struct. */
>> > > +} svn_wc_conflict_version_t;
>> >
>> > The structure's alloc and dup functions should be here.
> [...]
>> > If the struct is public then its alloc and dup functions should be
>> > public too. (And if one is private they all should be private.)
>>
>> I don't think clients will ever need to allocate this structure
>> directly. They will always be getting it from libsvn_wc.
>> However, they need to be able to read the fields.
>>
>> That's why the struct itself is public while the functions are
>> private. Should we document this in the struct docstring?
>>
>> Something like:
>> + * Clients are not expected to be allocating this structure
>> + * directly.
>
> I get a bit muddled about public/private considerations. I argued that
> the add/del/get-tree-conflict functions should be private to Subversion.
> Now we are adding tree conflict data to this structure that is already
> public, and we are considering whether to keep its alloc and dup
> functions private. I think the answer here is that that alloc and dup
> functions are "part of" the proper semantic definition of a data
> structure. Note that C++ requires[1] an alloc function ("constructor")
> and a dup ("copy constructor") for every class. The semantics and
> backward-compatibility issues of these functions are simple, so there
> should be no problem with making them public. A client might want to
> keep copies of these structures outside the pool that we provide them
> in, so there is a need for them to be public.
>
> Neels made them public in the branch.
>

I was talking yesterday with Nico Schellingerhout, creator of the
trumerge tool for tree conflict handling in Subversion 1.4, and BTW a
customer of ours (elego's). He suggests that a new version of
trumerge for svn 1.6 could look for cases that we don't yet catch
(such as use case 5) and use the working copy library to set new
tree conflicts.

Is it possible for a third-party tool to create a new tree conflict?

Thanks,
Steve

--
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org