subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svn commit: r1498873 - in /subversion/trunk/subversion: libsvn_wc/entries.c libsvn_wc/tree_conflicts.c libsvn_wc/tree_conflicts.h libsvn_wc/upgrade.c tests/libsvn_wc/conflict-data-test.c
Date Tue, 02 Jul 2013 13:50:34 GMT


> -----Original Message-----
> From: stsp@apache.org [mailto:stsp@apache.org]
> Sent: dinsdag 2 juli 2013 12:40
> To: commits@subversion.apache.org
> Subject: svn commit: r1498873 - in /subversion/trunk/subversion:
> libsvn_wc/entries.c libsvn_wc/tree_conflicts.c libsvn_wc/tree_conflicts.h
> libsvn_wc/upgrade.c tests/libsvn_wc/conflict-data-test.c
> 
> Author: stsp
> Date: Tue Jul  2 10:40:22 2013
> New Revision: 1498873
> 
> URL: http://svn.apache.org/r1498873
> Log:
> Make svn_wc__serialize_conflict() and svn_wc__deserialize_conflict() use
> the
> new conflict description structure (svn_wc_conflict_description3_t).

I'm not sure if this is really what we want here. If we move this forward with the new infrastructure
we have to rev it every kind when we upgrade, while it is really only used for providing svn_wc_entry_t
to 1.6 style API uers, and for the upgrade from 1.6.

The serialization format here is locked to what we used then, and I don't know if our future
in-memory-conflict data will be anything like a struct that can both be read and written.

If we have to keep the compatibility api anyway, we can just use it here and avoid revving
all this in future versions.

	Bert


Mime
View raw message