On Tue, Nov 20, 2007 at 01:21:55AM +0000, Julian Foad wrote:
>>> 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.
Great, thanks :)
> 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.
I can't commit directly, but I can post a patch.
We might as well start ASCII-fying the other use cases so
we have all the uses case descriptions from the paper in
the tree.
>>> 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.)
They can't be printed, because they would be very, very long
error messages, and the hacker's guide says errors more than
70 characters long are a no-no.
> It feels wrong to be putting this human-readable stuff in as the canonical,
> programmatic representation of the state.
It does. The design is lacking a bit here so far.
A related problem is how to keep information about tree conflict
state in the working copy up to date. Whenever an update is done,
new tree conflicts may be added, and whenever a conflicts is resolved,
tree conflicts might go away.
Relying only on the description file, we'd have to parse it
and add/remove information about new/former victims but leave
information about untouched victims in place. And we need
to modify the file in a loggy way to prevent chaos when
interrupted while making changes.
All this gets hairy if the description file is our only store
of information about tree conflicts, especially given that
svn_wc__loggy_append() is not idempotent (see issue #3015).
So we'd like to extend the design a bit so that tree conflict
information is stored in a special wcprop, from which the
description file can be derived. This makes it easier to
keep the description file in sync with what is actually
happening to a tree-conflicted directory.
The property could store a string like:
foo.c:update_deleted:we_edited|filename\:withcolon.h:merge_edited:we_deleted|...
to describe each tree conflict in the directory containing
the wcprop.
Whenever we need to add or remove a tree conflict victim,
we would use svn_wc__loggy_modify_wcprop() to update the
propery with a new value. To update the user-visible
description we have a function that reads the property,
creates human-readable discriptions from it, and uses
svn_io_open_unique_file2() and svn_io_write_full()
to create a new temporary description and svn_wc__loggy_move()
to overwrite the real description.
Any better ideas?
> 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!"
The GUI could get the filename and show the conflict description
in a pop-up window, for example. (So exposing the filename
via API might be useful after all...)
> 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.
The problem is that CollabNet needs something that is compatible
with 1.5, so we cannot extend the API. I know this sounds crazy,
and I'd rather be able to design away without having to worry
about API changes, but our task at hand is about getting it to
work somehow so it can be integrated into 1.5.x.
I don't see any problem with adding such an API in 1.6 however.
> I don't think this is quite the same as the situation with the ".mine"
> files.
You're correct, it's not. Sorry for saying this, it's confusing
the issue.
> 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.
I don't really like it either, but property conflicts are handled
in a similar fashion:
$ ls
dir/
$ svn propget property dir
value2
$ svn commit dir -m "changed dir prop"
Sending dir
svn: Commit failed (details follow):
svn: Out of date: '/dir' in transaction '2-1'
$ svn up
C dir
Updated to revision 2.
$ svn commit dir -m "changed dir prop"
svn: Commit failed (details follow):
svn: Aborting commit: '/tmp/wc/dir' remains in conflict
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
IMHO this error message could at least tell the user
to look at dir_conflicts.prej...
$ ls dir/
dir_conflicts.prej
$ cat dir/dir_conflicts.prej
Trying to change property 'property' from 'value1' to 'value3',
but property already exists with value 'value2'.
> What do GUI authors think of this?
Probably the same they think of property conflicts? :)
Steve just tested the way tortoise handles property conflicts.
It does not seem to be any more user-friendly than the CLI client.
It just shows the same error message in a pop-up, the dir_conflicts.prej
file is a regular file, and there seems to be no special option in
the context menu of neither the dir_conflicts.prej file nor the
containing directory.
> 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.
Yes.
--
Stefan Sperling <stsp@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
- application/pgp-signature attachment: stored
Received on Tue Nov 20 15:44:14 2007