RE: What to expect from svn_fs_paths_changed2() call on branching revision

Hi,

Before step 3 your working copy is in mixed revision mode. (Some files are
from an older revision than the one just committed).

You would see that the specific file you see (/branches/0.3/subdir/sub2) was
copied from a different version of the parent directory then the parent
directory itself.

(svn status -v or svn info -R shows you this information before the copy;
svn log or the result of your call after the copy)

A copy of a directory on the subversion repository is always a copy of a
directory and all its children, unless some children have a different
action. (In the working copy you can sometimes see some non-operational
modifications below a copy destination, but these are filtered while
committing).

                Bert

From: Davyd McColl [mailto:davydm_at_gmail.com]
Sent: maandag 25 mei 2009 10:00
To: users_at_subversion.tigris.org
Subject: What to expect from svn_fs_paths_changed2() call on branching
revision

Good day. As the subject suggests, I'm a little fuzzy on what I should
expect to get back from an svn_fs_paths_changed2() call. Please
bear with me as I explain:

I have three seemingly dissimilar result sets from
svn_fs_paths_changed2() calls on branches, obtained as follows:

1) I have an svn repo with the following paths in it:
/trunk/
/trunk/hw.c
/trunk/hw.h
/branches/

When I do:

svn cp trunk braches\0.1

from the directory above trunk in my working copy, I get the
expected working copy layout:

/trunk/
/trunk/hw.c
/trunk/hw.h
/branches/
/branches/0.1
/branches/0.1/hw.c
/branches/0.1/hw.h

performing an "svn commit" and checking out somewhere else, I
can see the new branch and all files. Doing
svn_fs_paths_changed2() on the repo at the revision of the commit,
I get the expected changeset of added files/dirs:

/branches/0.1 (added, copied from /trunk)
/branches/0.1/hw.c (added, copied form /trunk/hw.c)
/branches/0.1/hw.h (added, copied from /trunk/hw.h)

So far, all good.

2) Some time down the line, /trunk has in it:

hw.c
hw.h
subdir/
subdir/README.txt

I decide to branch again; doing:

svn cp trunk branches/0.2

from above trunk and the following paths appear in another working copy upon
an svn update:

/branches/0.2/
/branches/0.2/hw.c
/branches/0.2/hw.h
/branches/0.2/subdir/
/branches/0.2/subdir/README.

txt

(as expected). However, performing svn_fs_paths_changed2()
on the repo at the relevant revision only shows:

/branches/0.2/ (added, copied from /trunk)
/branches/0.2/subdir (added, copied from /trunk/subdir)

So the copied files aren't mentioned? apr_hash_count on the
returned changed_paths apr_hash_t also only counts 2
changes -- but what about the 3 files that were copied?
If they aren't mentioned here because it's implicit in a dir
copy that the files within are copied (fair enough), then why
are the files mentioned on the copy (1) above? Anyway, here
comes the third case, which really makes the water
muddier:

3) I create a dir:

mkdir /trunk/subdir/sub2/

and add a file:

echo "foo" > /trunk/subdir/sub2/arf.txt

I svn add them and svn commit. Checking out elsewhere
shows that the changes are in place. I now do:

svn cp trunk branches/0.3
svn commit -m "0.3 branch"

Again, checking out from / somewhere else gives me
all of the expected files and folders. However, doing
svn_fs_paths_changed2() on the repo at the branch
revision shows only the following changes:

/branches/0.3 (added, copied from /trunk)
/branches/0.3/subdir/sub2 (added, copied
                            from /trunk/subdir/sub2)

Ok, now I'm lost. Why is the copy of
/trunk/subdir to /branches/0.3/subdir omitted if
the child (/trunk/subdir/sub2) is to be mentioned?

I'm trying to use the version control and hooks in svn
to underly another system I'm building, so I really need
to be able to examine, at the svn fs level, the changeset
for a revision in a repository.

Originally, I thought that svn fs routines wouldn't tell
me about copies of files within dirs copied via a copy
transaction and was going to grok the copied files
by querying the contents of the source dirs to be
copied. However, doing an initial test copy operation
showed me the behaviour I see in (1) above, so I
expected the behaviour as per (1) to happen all of the
time (since I hadn't bothered to check branching of
a dir containing a dir yet). Just today, however, I find
seemingly incongruous (and unpredictable, from
what I've seen so far) behaviour in the changeset
reported by svn_fs_paths_changed2() for different
branch operations.

I would really appreciate some insight into what
I should expect to see returned from
svn_fs_paths_changed2() calls so that I can deal
with the changes in a revision. Should I expect:

1) A full set of all paths copied?
2) A full set of all dirs copied, from which I have
    to infer the copied file paths?
3) Something in between -- and then how do I
    predict which blanks I will have to fill in?

To add even more confusion, I've attempted to
use svn_respo_get_logs4() calls on the same
repo for the same revisions, setting
discover_changed_paths to TRUE . All calls
come back with SVN_NO_ERROR (null), but
my svn_log_entry_receiver_t funcion is never
invoked?!

Is there something I'm missing here? What
is the recommended method for getting a
list of paths that have changed in a commit?
It seems that I'm sorely missing something
here: svn_fs_paths_changed2() suggests,
by title, that it will give me a list of all the
paths changed (but doesn't),
svn_repos_get_logs4 promises me the same
but never invokes my callback. Please help.

Apologies for the very long first post. Any
comments or help appreciated.

-d

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Truth doesn't cease to be just because you don't agree with it.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2353470
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].