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

Re: Special revisions for conflicted files

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 27 Nov 2012 17:16:24 +0000 (GMT)

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
Received on 2012-11-27 18:17:03 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.