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

Re: simple tree conflict detection

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2007-11-20 02:21:55 CET

Stefan Sperling wrote:
> On Sun, Nov 18, 2007 at 12:15:23AM +0000, Julian Foad wrote:
>>Stephen Butler wrote:
>>
>>> SIMPLE TREE CONFLICT SIGNALING AND PERSISTENCE
>>>Issue reference: http://subversion.tigris.org/issues/show_bug.cgi?id=2282
>>>See also subversion/notes/tree-conflicts/use-cases.txt.
>>
>>Unfortunately there's a mis-match in use-case numbering.
>>
>><http://subversion.tigris.org/issues/show_bug.cgi?id=2282>
>>(in CMP's comment, July 2007) lists five cases. The issue, and these cases,
>>are assumed to be relevant to both "svn update" or "svn merge".
>>
>><http://svn.collab.net/viewvc/svn/trunk/notes/tree-conflicts/use-cases.txt?view=markup>
>>(r27454) shows three cases, explicitly relevant to "svn update".
>
> We never based our work on the 5 use cases in Michael's comment.
> That's why the numbering does not match.
[...]

Thanks! The references to numbers that don't exist in the text file were confusing.

As for me quoting the five brief phrases as "cases", yes I agree they are far
too vague on their own, but I assumed they corresponded to some precise
descriptions that I couldn't see.

[...]
> If you do not describe a tree conflict use case in detail it is
> likely that there are other similar use cases that fit the
> description just as well.

Very well said.

> I think the way it was done in the paper is a great example.
> I would vote for all use case descriptions of tree conflicts in
> the future to follow the same or a similar pattern. We've adapted
> it in notes/use-cases.txt.

Sounds good to me.

> A question that came up during the design was whether we should
> still allow commits of non-victim files from a directory that contains
> tree conflict victims. We opted against allowing this, assuming that
> a tree conflict is a worst-case scenario that requires immediate
> attention before any other changes are made to the tree-conflicted
> part of the project.

That sounds not ideal but OK: safe and not too onerous.

>>That paper would be the file "tree-conflicts-use-cases-svn-1.4.ppt".
>>Unfortunately I can't read MS PowerPoint files.
>
> Neither can I without compiling open office for hours.

Duh... I have OpenOffice installed. Didn't realise it could open PowerPoint
docs. It can export to PDF, so I've done that and attached the PDF version to
the issue.

Please would you commit a clarification to use-cases.txt explaining to what
degree it corresponds to the cases in the .ppt paper, and make it explicitly
list the case numbers that are not there. Or delete it if it's not adding value.

>>It might be very helpful if
>>you could replace it with a more accessible version - text or PDF or PNG
>>for example.
>
> We did exactly that. The result is in notes/tree-conflicts.txt.

(which has since been moved/renamed to "notes/tree-conflicts/use-cases.txt")

> Descriptions of use cases 4 to 6 in the .ppt are still missing
> but will be added soon.

[...]

>>> /* Return the name of the file containing tree conflict descriptions
>>> * for all tree conflicts marked in DIR_PATH. */
>>> const char*
>>> svn_wc__get_tree_conflict_descs_path(const char *dir_path,
>>> apr_pool_t *pool);
>>
>>I wouldn't deliberately expose the file itself, because we are likely to
>>want to change the method of storing this information later to use
>>something else other than a file, or to change the format of the file.
>
> The file is user visible anyway, as are .prej and .mine files.

But I'm saying we shouldn't specify that it's necessarily user-visible.

> Looking at it now I think that function can be removed.
> It was there because I was planning to point the user
> to the filename in the error message upon commit.
>
> But because conflict file names aren't mention on text and
> property conflicts either it is inconsistent and we dropped
> that (even though I still think it would improve usability...)
>
>
>>Instead, provide an API to get the conflict descriptions (one at a time or
>>all at once).
>
> We don't really need that. For now, we expect the user to look
> at the file to figure out what's going on, just as with .prej
> and .mine files on property and text conflicts.
>
>>I won't worry about the human-readable descriptions yet.
>
> We have to worry about this, the reason is in the above paragraph.

Oh I see: those are the descriptions to appear in the conflict-description
file. (Sorry, I was imagining them being printed on screen during the
operation, for some reason.)

It feels wrong to be putting this human-readable stuff in as the canonical,
programmatic representation of the state. How is TortoiseSVN supposed to
display the result? "Hey, user, you've got conflicts. You can find out what
they are by loading up the following text file in your favourite text editor!"
Sorry, I'm being facetious, but you get the idea: unless I'm missing something,
there ought to be a programmatic WC API for listing the conflicts.

If we have them listed in human-readable form in a visible file as well as the
API, that's maybe OK, and maybe wee wouldn't bother providing in the
command-line client any way of reporting the details, because the user can just
read the text file. But not OK for other clients.

I don't think this is quite the same as the situation with the ".mine" files.
I'm not familiar with the property conflict handling. If human-readable text in
the ".prej" file is the only way to find out about property conflicts, then I
see where you are coming from, but I still don't like it.

What do GUI authors think of this?

I suppose an API could always be added later, and the human-readable text
changed then to be more machine-readable as well, without significant
backward-compatibility problems.

Regards,
- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 20 02:22:14 2007

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