You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@red-bean.com> on 2008/03/22 23:22:38 UTC
Re: svn commit: r30009 - trunk/subversion/libsvn_wc
dionisos@tigris.org writes:
> --- trunk/subversion/libsvn_wc/update_editor.c Sat Mar 22 07:33:07 2008 (r30008)
> +++ trunk/subversion/libsvn_wc/update_editor.c Sat Mar 22 13:54:37 2008 (r30009)
> @@ -2621,8 +2621,10 @@ merge_file(svn_wc_notify_state_t *conten
> SVN_ERR(svn_wc__loggy_entry_modify(&log_accum, adm_access,
> fb->path, &tmp_entry, flags, pool));
>
> - /* Log commands to handle text-timestamp and working-size */
> - if (!is_locally_modified)
> + /* Log commands to handle text-timestamp and working-size,
> + if the file is - or will be - unmodified and schedule-normal */
> + if (!is_locally_modified &&
> + (fb->added || entry->schedule == svn_wc_schedule_normal))
> {
> /* Adjust working copy file unless this file is an allowed
> obstruction. */
Shouldn't it be
(!is_locally_modified &&
(fb->added
|| fb->added_with_history
|| entry->schedule == svn_wc_schedule_normal))
? That is, don't we need to accept the 'replaced' case too?
(By the way, I think 'struct file_baton' under-documents its 'added'
field, since it's not entirely clear whether 'added_with_history' always
implies 'added', or whether the former can be true while the latter is
false.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r30009 - trunk/subversion/libsvn_wc
Posted by Karl Fogel <kf...@red-bean.com>.
"Erik Huelsmann" <eh...@gmail.com> writes:
> To answer your question: I think the answer is 'no': fb (file-baton)
> is about what we're being sent from the server. Replacements will be
> sent as D+A, meaning that the A code-path will be executed and 'added'
> will be TRUE. The 'added' transformation presumably leads to a new
> 'schedule-normal' file in the Working Copy.
Ah, okay. Good explanation, thank you.
> If the file wasn't added, but updated, then, if the file was
> 'replaced-with-history', we don't need to cache the working size and
> time, since those serve to detect whether the target is a committable:
> it already is. (BTW: Is receiving an update for a
> replaced-with-history file a tree conflict?)
Properly, I think that depends on the history of what it was replaced
with. Practically, I'm not sure how much it matters: the update either
will or won't textually conflict.
> In any other case, since the schedule isn't normal anyway, I don't
> think we need to cache the WC file metadata.
*nod*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r30009 - trunk/subversion/libsvn_wc
Posted by Erik Huelsmann <eh...@gmail.com>.
On Sun, Mar 23, 2008 at 12:22 AM, Karl Fogel <kf...@red-bean.com> wrote:
> dionisos@tigris.org writes:
> > --- trunk/subversion/libsvn_wc/update_editor.c Sat Mar 22 07:33:07 2008 (r30008)
> > +++ trunk/subversion/libsvn_wc/update_editor.c Sat Mar 22 13:54:37 2008 (r30009)
> > @@ -2621,8 +2621,10 @@ merge_file(svn_wc_notify_state_t *conten
> > SVN_ERR(svn_wc__loggy_entry_modify(&log_accum, adm_access,
> > fb->path, &tmp_entry, flags, pool));
> >
> > - /* Log commands to handle text-timestamp and working-size */
> > - if (!is_locally_modified)
> > + /* Log commands to handle text-timestamp and working-size,
> > + if the file is - or will be - unmodified and schedule-normal */
> > + if (!is_locally_modified &&
> > + (fb->added || entry->schedule == svn_wc_schedule_normal))
> > {
> > /* Adjust working copy file unless this file is an allowed
> > obstruction. */
>
> Shouldn't it be
>
>
> (!is_locally_modified &&
> (fb->added
> || fb->added_with_history
>
> || entry->schedule == svn_wc_schedule_normal))
>
> ? That is, don't we need to accept the 'replaced' case too?
> (By the way, I think 'struct file_baton' under-documents its 'added'
> field, since it's not entirely clear whether 'added_with_history' always
> implies 'added', or whether the former can be true while the latter is
> false.)