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
