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

Re: svn commit: r26953 - branches/svnpatch-diff/subversion/libsvn_client

From: Charles Acknin <charlesacknin_at_gmail.com>
Date: 2007-10-06 00:33:38 CEST

On 10/5/07, Daniel L. Rall <dlr@finemaltcoding.com> wrote:
> How is this different from the information tracked by --dry-run deletions?
> I have a patch which converts the --dry-run-specific deletions stuff into
> something more generic. It turns out that sussman may want to use this
> information to handle use of the update editor with copied/moved files.

Hmm, I'm looking with despair for the TODO line I had written in the
docstring of the deletions hash, but it seems like I removed it when
cleaning up the place before I commit. Ok so basically it was saying
"TODO: see whether we can merge this hash and dry_run_deletion hash in
one". I haven't had time to sort this out yet.

[a few minutes later after trying to figure out how the
dry_run_deletion hash work]

If I understand correctly, it seems like the dry_run_deletions hash is
here to compensate for items on disk not being deleted since we're in
a dry-run mode, and then do the right thing with the notification as
the file is still there when checking on disk.

Well, the deletions hash I'm using here is quite different. Its
purpose is to solve a problem I faced when dealing with file and
directory move operations. Since svnpatch is using Editor Commands,
when applying the patch the editor is being driven in a depth-first
manner. Because of this and the fact that moves are represented in
two unordered and interchangeable operations add-with-history and del,
when the del precedes the add-with-history the WC file we want to copy
is gone when needed. The hash is basically used to prevent this. It
used in two ways since we have two cases:

  * del and add: the hash is used to store schedule-delete entries; we
also use keep_local when calling svn_client__wc_delete() so that the
file remains until add is called, do the copy, and then lookup the
hash to actually delete the file from disk.

  * add and del: the hash is used to say "I --merge_file_added-- was
called with this copyfrom-path information and I did make a copy. I
don't know whether I'm part of a move operation or just a copy, but
who knows, I'm going to insert this copyfrom-path into the deletions
hash"; then, possibly, if/when a del command is found, it knows that
it's fine to remove the file from disk when the path it is about to
delete exists in the deletions hash.

Hope it's clearer now :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 6 00:33:46 2007

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.