[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: dir_delta behavior

From: <cmpilato_at_collab.net>
Date: 2002-02-01 16:31:59 CET

Ben Collins-Sussman <sussman@collab.net> writes:

> Yo Cmike:
>
> When I run a command like:
>
> svn switch A/D/H file:///.../A/B
>
> dir_delta() seems to work fine. It happily adds all of B's entries,
> then it happily deletes all of H's entries. The anchor of the update
> (A/D/H) never changes its name, and it's entries-url is modified to
> point to B.
>
> But I forsee future problems: specifically, it seems Bad that
> dir_delta is sending additions before it sends deletions. What if I'm
> switching to a directory that contains a file with an identical name
> to one I already have?
>
> * In the common case, the two files with identical names will be
> related. (If say, I'm switching to some branch.) In that case,
> I'll just see a "U" on the file.
>
> * In the uncommon case, the files may be totally unrelated, in which
> case dir_delta wants to do to a true replacement. But to do that,
> shouldn't it be sending a delete before an add? Otherwise we're
> in for an "obstructed update" error.
>
> Cmpilato, please share your wisdom. Does dir_delta need to be tweaked
> to send deletes before adds? If so, will this screw anything else up?

This from delta_dirs():

  /* Loop over the hash of entries in the target, searching for its
     partner in the source. If we find the matching partner entry,
     use editor calls to replace the one in target with a new version
     if necessary, then remove that entry from the source entries
     hash. If we can't find a related node in the source, we use
     editor calls to add the entry as a new item in the target.
     Having handled all the entries that exist in target, any entries
     still remaining the source entries hash represent entries that no
     longer exist in target. Use editor calls to delete those entries
     from the target tree. */

For all children of the directories being compared that have the same
name, ancestry comparisons are performed, and one of three conclusions
made:

1. Are they the same node? Do nothing.

2. Are they related? Then just call editor->open_xxx(), sending
    textdeltas in the file case, and recursing into delta_dirs in the
    directory case.

3. Are they unrelated? editor->delete(); editor->add().

Here's the code (with some non-operative #defines stripped out for
your reading convenience):

              if (distance == 0)
                {
                  /* no-op */
                }
              else if (distance == -1)
                {
                    {
                      /* We found no ancestral match at all. Delete this
                         entry and create a new one from scratch. */
                      SVN_ERR (delete (c, dir_baton, t_entry->name, subpool));
                      SVN_ERR (add_file_or_dir
                               (c, dir_baton, NULL, NULL,
                                target_path, t_entry->name, subpool));
                    }
                }
              else
                {
                  SVN_ERR (replace_file_or_dir
                           (c, dir_baton,
                            source_path,
                            s_entry->name,
                            target_path,
                            t_entry->name,
                            subpool));
                }

Once things with the same name are out of the way, we're left with two
sets of entries: thing in the target not in the source, and things in
the source not in the target. Add the former, delete the latter, and
the order doesn't really matter because they have necessarily
different names.

Benny didn't read the code.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:03 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.