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

[Bert Huijben <rh...@sharpsvn.net>]

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@gmail.com] 
Sent: maandag 25 mei 2009 10:00
To: users@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@subversion.tigris.org].

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

[Davyd McColl <da...@gmail.com>]

On Mon, May 25, 2009 at 3:25 PM, Bert Huijben <be...@qqmail.nl> wrote:

>                  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
>
I'm afraid I don't follow you at all. Perhaps I'm just a little slow...

First I must make sure that we're on the same page: at every case point
above, there was nothing uncommitted when
looking at the output from svn_fs_paths_changed2() or the result of 'svn log
-v -r <revision>'. In other words, the branch isn't made from an uncommited
/trunk. I added dirs and files; committed; then branched.

I would _always_ expect that the same paths mentioned by 'svn log -v -r
<revision>' should be mentioned when performing
svn_fs_paths_changed2() on the repository for that revision. If not, it
makes the svn_fs_paths_changed2() call a little underwhelming in
functionality, especially considering the misleading name which suggests
that I could use the function to.. well.. list the paths that were changed
on a repo in a revision commit. To my mind, making a copy (even a light one,
the analogy of a symlink), is still a "change of paths": there's a new copy
path in the repo that wasn't there before the commit transaction. Am I
horribly mislead in believing this?

* If only the base directory being copied is supposed to be mentioned, then
why do we have the output from (1) (all copied items mentioned)?
* If only items with a different version from the copied branch are to be
mentioned (what I understand you to mean by "mixed revision mode" and your
explanation as to why I only see /branches/0.3/subdir/sub2), then, once
again, there shouldn't be as much output for situation (1) above, since all
paths in the original branch are from the same version as the copied base
path. Or is there some other criteria for deciding what is "new" enough to
be mentioned in the svn_fs_paths_changed2() call for the copy transaction?

I understand that a copy of a directory on the repo should always contain
the children of the source -- though your proviso "unless some children have
a different action" concerns me a little -- I assume here that you are
meaning that one transaction was used to encapsulate a delete (for example)
from the source before the copy was done, in which case the copy obviously
won't include that child node.

Perhaps, if you have a little time to spare, you could clarify for me a
little. I'm still unconvinced that what I'm seeing isn't completely
unexpected behaviour. I'm currently building functionality to "fill in the
blanks", where my set of changed paths will have the unmentioned copied
paths in it, but I'm concerned that the copied base may, at some point, be
considered "uninteresting" and omitted from the list. I'm also still
concerned as to why only some of the copied paths are mentioned at all.

Once again, your input is appreciated. I haven't had any sort of answers by
looking through the subversion documentation or source, nor has google been
particularly enlightening.

-d

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2353472

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].