RE: svn commit: r1030912 - in /subversion/trunk/subversion/libsvn_wc: adm_crawler.c update_editor.c

> -----Original Message-----
> From: cmpilato_at_apache.org [mailto:cmpilato_at_apache.org]
> Sent: donderdag 4 november 2010 13:46
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1030912 - in
> /subversion/trunk/subversion/libsvn_wc: adm_crawler.c update_editor.c
>
> Author: cmpilato
> Date: Thu Nov 4 12:45:39 2010
> New Revision: 1030912
>
> URL: http://svn.apache.org/viewvc?rev=1030912&view=rev
> Log:
> Attempt to fix issue #3665 ("Double update of versioned file externals
> corrupting file timestamps") by trying to better preserve the
> two-phase handling of working copies with externals in the
> file-external case, too.
>
> My approach is two-fold. First, teach the reporter driver to not
> report file externals as switched items when they are crawled as part
> of a crawl of their parent directory (as opposed to when they are
> crawled explicitly). This should cause the server to stop sending
> updates for them. Secondly, teach the update editor code to not claim
> that file externals which were not the explicit target of the
> update/switch were updated when, in fact, they weren't.
>
> (I'm not particularly confident that this doesn't break something else
> in a mysterious fashion.)

Some time ago I hinted about creating a special wc-ng status for 'pinned' nodes.

This would introduce a well defined foundation in wc-ng that we can use for both file-externals (now) and viewspecs (later).

The simple definition for 'pinned' I had was: only valid on BASE (op_depth 0) nodes and handled as status 'normal'. The only exception to handling as normal would be that the adm crawler reports these nodes as excluded (like this patch does) so a second step could update them (from a different path, revision and/or repository).

The current file externals implementation still lacks documentation and a proper design and I'm -0 to -1 on extending file externals support (like that in this commit) without creating a proper design for file externals first.

The pinned status would make it very cheap to check for these relatively uncommon special nodes in a working copy, while adding a check for file-externals adds an extra database query to the most common code path in the update editor.

        Bert
Received on 2010-11-04 14:08:25 CET