>sufficient, because, for example, "svn commit" followed immediately by >"svn up" should be guaranteed to update the WC to at least the revision >number of the commit, whereas with the proposed operation-name scheme I >think it would update to the last cached revision which can be older >than the commit.
This was the case I gave patch few months back which got a negative reaction as it was exposing the proxy details to the mod_dav_svn's update_editor code. Now this patch does not affect its behaviour. wc_from_slave$svnversion 41 wc_from_slave$modify something wc_from_slave$svn ci -m "commit" Committed 42 wc_from_slave$svnversion 41:42 wc_from_slave$svn up With this patch the 'svn up' scenario works as follows, Get the HEAD from the server via PROPFIND which would be unaffected with our patch as it is not for the 'commit' operation, i.e no preceding MKACTIVITY or SVN-ACTION != commit so *no* proxying to Master. Without this patch the 'svn up' scenario works as follows, Get the HEAD from the server via PROPFIND which is not proxyed to Master. After getting the HEAD *from*(not Via) the Slave it runs the update editor for 'r41' with one of the child being in r42 to get update editor confused(That is what my patch was handling and gave a meaningful/less frightening message). With regards Kamesh Jayachandran
