Howdy folks.
I was talking to Mike a couple of weeks ago.
When we get a property conflict, we store a message in "<filename>.prej"
that says:
> Trying to change property 'p' from 'v1' to 'v2',
> but property has been locally changed from 'v1' to 'wcval'.
That's OK for a short plain-text value, but is not human-readable for a
very long value or a "binary" value, and not machine-parseable if the
value contains a single-quote character.
Mike and I agree it's totally obvious - "d'uh" - that we should store
the "old" and "theirs" and "mine" values in a more rigorous,
programmatically-accessible form, as we do for the file text in a file
text conflict. This would enable tools built on top of Subversion to
offer proper property conflict resolution.
I see two solutions (Mike, I only thought of (1) until after talking to
you last week, and then I realised you were probably thinking of (2)):
(1) Save the item's "old", "theirs" and "mine" properties in the admin
area if there is any property conflict on the item.
* Save each of these three sets of properties as a property hash file,
just like the "base" properties file.
* Provide APIs (and possibly a UI in "svn") to read these properties
in a way that is very similar to reading the base properties.
(2) For each property that conflicts, create "old", "theirs" and "mine"
files holding the bare value of that property in the user's WC
directory. (This is where we write the files for text conflicts.)
* Provide a way to access the names of these files. (They can't be
quite as simple as "<filename>.old" as there can be multiple properties
conflicting on one item.)
With (1), we store all the properties if any of them conflict. If a
property that conflicts is closely related to another property that
doesn't, say "svnmerge-integrated" and "svn:mergeinfo", then both
properties' values will be available to help the user in the resolution.
Solution (1) requires a libsvn_wc API to retrieve the old/theirs/mine
properties, and a UI extension if we want "svn" users to benefit.
Solution (2) requires exposing the file names through svn_wc_entry_t,
and optionally exposing them to the user through "svn info", or perhaps
through text in the existing "<filename>.prej".
I have implemented the basics of (1): that is, storing the properties,
an API to retrieve them, and a suggestion for a UI. The "retrieve" API
looks something like this:
> Index: subversion/include/svn_wc.h
> ===================================================================
> svn_error_t *
> svn_wc_prop_list(apr_hash_t **props,
> const char *path,
> svn_wc_adm_access_t *adm_access,
> apr_pool_t *pool);
>
> +/* A type to specify which of the versions held in the WC. Types 'pristine'
> + * and 'working' are always meaningful (though they may be in the
> + * "nonexistent" state), whereas types 'conflict_*' are only valid when the WC
> + * item is in a state of conflict. */
> +typedef enum svn_wc_rev_kind_t
> +{
> + svn_wc_rev_kind_pristine, /* the 'pristine' or 'base' version */
> + svn_wc_rev_kind_working, /* the version that can be locally edited */
> + svn_wc_rev_kind_conflict_old, /* the incoming change's 'old' or 'left' side */
> + svn_wc_rev_kind_conflict_new, /* the incoming change's 'new' or 'right' side */
> + svn_wc_rev_kind_conflict_mine /* what was 'working' before the conflict */
> +} svn_wc_rev_kind_t;
> +
> +/** Set @a *props to a hash table mapping <tt>char *</tt> names onto
> + * <tt>svn_string_t *</tt> values for all the regular properties of
> + * @a path. Allocate the table, names, and values in @a pool. If
> + * the node has no properties, or does not exist in the working copy,
> + * then an empty hash is returned. @a adm_access is an access baton
> + * set that contains @a path.
> + * @a rev_kind specified whether to access the pristine or working or
> + * one of the conflict artifact versions of this WC item.
> + */
> +svn_error_t *
> +svn_wc_prop_list2(apr_hash_t **props,
> + const char *path,
> + svn_wc_rev_kind_t rev_kind,
> + svn_wc_adm_access_t *adm_access,
> + apr_pool_t *pool);
> +
I can then see a command-line UI something like
svn propget --conflict-artifact=old|theirs|mine TARGET
The sort of ultimate solution I would like to see at some point in the future would be one where all svn commands could access these pseudo-versions just as easily as they can access BASE or WORKING:
svn propget -r mine TARGET
... and have the file content conflict versions handled the same way, so:
svn cat -r theirs TARGET
svn diff -r old:theirs TARGET
svn merge -r123:theirs TARGET wc
Maybe pie-in-the-sky unrealistic for this season, but I think a move towards it are good. This kind of capability is what we will the user will eventually need to properly resolve large and complex tree conflicts. It is also something that I expect WC-ng will make much easier to implement.
Comments?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-14 14:24:04 CEST