On Mon, May 25, 2009 at 3:25 PM, Bert Huijben <bert_at_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_at_subversion.tigris.org].
Received on 2009-05-25 15:45:00 CEST