Markus Schaber wrote:

> Currently, we have special revisions "WORKING", "HEAD", 
> "BASE", "COMMITTED", "PREV" which can be used 
> internally in the API, as well as for "svn cat".
> 
> What about defining additional special revisions for conflicted files, like 
> "OLDER" and "INCOMING"?
> 
> This would allow "offline" conflict resolving mechanisms to access the 
> files involved in a conflict the same way as it can currently access BASE, 
> WORKING and HEAD revisions.
> 
> Just a weird idea, but it would have saved me a bunch of special-casing in my 
> CODESYS SVN integration...

I have considered this before, a few years back, and I like it.

One of the difficulties is that currently (and more so in the past) the set of 
information stored for conflicts is rather sparse.  If the text conflicts, then 
we store the three versions of the text but not the three corresponding sets of 
properties, and vice versa.  A request for say "svn diff -rTHEIRS:MINE 
some/conflicted/file" would not be able to pull out a completely consistent 
view of the node "theirs", for example.  We'd have to say there are lots of 
exceptions.

Another difficulty is that the code is currently structured without much of a 
consistent API through which to query the different aspects of a given node.  
We'd be saying "-rTHEIRS" means you might get "their" version of the node's 
properties but the current working version of its text, or maybe you'll get the 
base version of its text, depending on what operation you're calling.

However, the good news re. the latter point is I'm working on a way to 
consolidate access to various revisions or more generally "layers" of a tree 
(which can be just a single node such as "some/conflicted/file").  I'm calling 
this "tree API" or "tree read API".  This doesn't in itself fix the former 
problem of not having stored the full snapshots of the different conflict 
versions, but it will introduce the concepts necessary to organize the 
THEIRS/MINE idea, and will also make it easier to provide a consistent kind of 
fallback for when only part of the info is available ("refer to THEIRS, falling 
back to WORKING for any parts you don't have").

- Julian

Reply via email to