AW: Svn Commit and unlock notifications

Hi, Bert,

Von: Bert Huijben [mailto:bert_at_qqmail.nl]
> From: Markus Schaber [mailto:m.schaber_at_3s-software.com]
> >
> > Hi,
> >
> > When svn_wc_notify_func2 is called with notify->action ==
> > svn_wc_notify_commit_modified, the field notify->lock_state is set to
> > svn_wc_notify_lock_state_unknown (value 1) instead of
> > svn_wc_notify_lock_state_unlocked.
> >
> > There also is no further notification that the lock is removed, the
> > svn_wc_notify_commit_postfix_txdelta notification equally carries
> > svn_wc_notify_lock_state_unknown.
>
> Yes, it takes code to set fields in a notification structure and the code
> that does these notifications doesn't do anything lock related. As far as
> I know only updates/switches really set these fields.
>
> > This happens with SharpSVN based on SVN 1.7.5, and may also affect the
> > other svn_wc_notify_commit_XXX notifications (not checked yet).
> >
> > Is this intentional, or a bug?
>
> I would call an addition of this notification a feature request.
>
> > I know that setting the lock state to unlocked when the
> > svn_wc_notify_commit_modified notification is sent might be a little
> > too early (as the commit still might fail), but then there should be a
> separate
> > unlocking notification at the time when the unlock actually takes place.
> >
> > My current workaround is that my code memorizes all the pathes where a
> > svn_wc_notify_commit_XXX notifications occurs, and after the commit
> > operation has finished successfully, it assumes all those pathes have
> > been unlocked.
> >
> > Can someone confirm that this will catch all unlockings? Or do I need
> > to I
> re-
> > check using svn_client_status5 to avoid false positives?
>
> This will give you all unlocks. Commit won't touch other paths than those
> processed.
>
> The only case where you might miss unlocks is when a parent of locked
> paths is deleted/replaced. In this case the commit won't tell you anything
> about the paths, but the BASE layer including the locks are silently
> removed.
>
> In AnkhSVN I remember all paths notified by the commit and perform a
> status-invalidate on them after the commit.
> (I remember those deleted/replaced paths with a different flag, to make
> sure I invalidate their status recursively)

This won't catch unmodified (but locked) paths which were selected for the commit (either directly or by recursion). Those paths are unlocked when there is at least one "real" modification which actually causes the commit to transfer data to the server.

So I guess AnkhSVN could profit from that feature, too.

Best regards

Markus Schaber

-- 
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915