On Thu, 2010-01-07, Kamesh Jayachandran wrote:
> >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.
That means the 'svn up' believes that HEAD==41 and so it runs the update
editor for 'r41' with one of the child being in r42, and that gets the
update editor confused. Yes?
That is part of my concern. I think we should try to find a solution to
the commit problem that also solves this case, because then I think we
will have solved a much more general problem, not just a specific case
that is related to the way the commit operation currently works.
I suggested some other ways in an earlier email,
<http://article.gmane.org/gmane.comp.version-control.subversion.devel/117051>, namely a client unique id or the client telling the server its last known head revision number. What do you think about those? (Never mind for the moment how to generate a unique id; let's first decide if that would solve the problem.)
- Julian
> 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
Received on 2010-01-13 14:01:17 CET