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

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

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 2 Jul 2013 15:50:34 +0200

> -----Original Message-----
> From: stsp_at_apache.org [mailto:stsp_at_apache.org]
> Sent: dinsdag 2 juli 2013 12:40
> To: commits_at_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
Received on 2013-07-02 15:51:37 CEST

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