Jakub Narebski wrote: > The major problem is that svn:log etc. are _unversioned_ properties (see > http://svnbook.red-bean.com/en/1.5/svn.ref.properties.html), so I am not > sure if there is a way for Subversion server to tell that some svn:log > properties changed. Perhaps there is a log, even if properties are > unversioned... otherwise we would have to detect somehow that properties > changed. There has been brief discussion of that possibility on the Subversion list [1]: "What we might need is an RA call that has the server provide the N last revisions to have undergone revprop edits..." I'm guessing that there is not such a log now but the developers might be open to a patch adding such a log (for the sake of svnsync and similar use cases, like this one). > Later we fetch again from SVN repository, and besides new revisions to > be converted we notice somehow that svn:log property for revision 'n' > changed from A to B. > > We now create replacement commit BB in Git, with the same Git parent > as commit AA, and with commit message changed to BB. Then we add > commit BB as replacement for AA: > > $ git replace -f AA BB Yes, exactly. In some cases, this "git replace" step would have to be accomplished by a separate command (or even "by hand") to get the job done: alice> git clone svn://svn.example.com/ upstream> svnadmin propedit ... bob> git clone svn://svn.example.com/ In this situation, alice and bob have diverging histories, just as if upstream had rewritten history (because, well, upstream has). Now if alice fetches from bob and notices that, then she must do alice> git replace AA BB (or its user-friendly equivalent, or a batch equivalent to search for and handle cases like this). [...] > If changes to unversioned revision properties are rare, then replacement > technique is much superior to using notes, which generates unnatural git > repository. When changing commit messages (svn:log) and the like are > common and often, which would result in great many replacements, the > notes technique could be better because of performance reasons. Exactly. Well, one can mitigate the performance problems by running "git filter-branch" every once in a while. :) Regards, Jonathan [1] http://thread.gmane.org/gmane.comp.version-control.subversion.devel/122840/focus=122944 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html