Stefan Sperling wrote:
> Ivan Zhakov wrote:
>> 3. I am not sure that the log adressing feature in the current
>> desing and implementaion is really valuable for users. On the other
>> side, we have the FSX format that is treated as experimental. The much
>> better way is to release log adressing feature in this new format and
>> see how it works in production (not during the alpha/beta testing).
>
> Like Julian, I don't see much of a difference between putting new
> changes into just FSX (leaving FSFS as it was in 1.8), and putting
> new changes into both FSX and FSFS. Users (and third-party vendors
> who offer SVN server implementations, in case this matters) will always
> have the option to keep using repositories in 1.8 format, even with a
> 1.9 server, if they feel the 1.9 FSFS format has not been proven stable.
> Remember that running 'svnadmin upgrade' is a manual step.
While I agree with that, I do also understand Ivan's concern about having a new format to maintain. That is a real difference between the two approaches.
>> As far as I can tell, the svn_fs_move() is never called (quite surprising).
>> Moreover, I'm unable to find any unit tests for svn_fs_move(). So it's not
>> worth to change the repository format for non-used feature.
>
> Agreed. But keep in mind that svn_fs_move() is marked experimental
> so we don't need to worry to much about the API.
>
> Though I'll note that svn_fs_path_change_kind_t has grown new
> move-related fields which aren't even marked as such:
>
> 1525419 stefan2 /** moved to this path in txn */
> 1525419 stefan2 svn_fs_path_change_move,
> 1525419 stefan2 /** path removed and replaced by moved path in txn */
> 1525419 stefan2 svn_fs_path_change_movereplace
>
> Those should be marked @since 1.9 at least. I've done so in r1585515.
> But I'm not sure if we can mark structure members as experimental,
> so this might need revisting...
>
> I'm most worried about the presence of a move-related option in 'svn log'
> since there doesn't seem to be any actual functionality behind it.
> I think this should be removed before release unless actual move-tracking
> features appear outside of the client's working copy. If it's needed for
> testing purposes, let's make it compile only with a special pre-processor
> flag or move development of the feature to a branch until it is complete.
+1 to all that about 'move'.
- Julian
Received on 2014-04-07 18:39:32 CEST