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

Re: Branch causes missing revs and errors merging

From: Frodak Baksik <frodak17_at_gmail.com>
Date: 2007-02-15 18:40:49 CET

On 2/15/07, Phillip Susi wrote:
> Please don't trim the Cc list.
>
> Frodak Baksik wrote:
> > How are you using diff?
>
> svn diff -r3 branch/foo
>
> > I mention it because I don't know how you determined that branch
> > exists in revision 1.
>
> If you do NOT use --stop-on-copy then the log of branch shows that it
> did exist back in rev 1, under the trunk.
>
> > $ svn ls file:///svn/repo/branch_at_1
> > svn: URL 'file:///svn/repo/branch' non-existent in that revision
>
> You used a peg revision, which is different. The name branch did not
> exist in rev 1. When you use a -r instead of a peg revision, the name
> gets resolved in HEAD, which works because the name branch exists there,
> but you specify that the state of the file should be tracked back to how
> it was in a previous rev. This is supposed to work for any and all revs
> in the file history back to the point where it was originally created.
>
> > $ svn ls file:///svn/repo/branch_at_2
> > svn: URL 'file:///svn/repo/branch' non-existent in that revision
> >
> > $ svn ls file:///svn/repo/branch_at_3
> > svn: URL 'file:///svn/repo/branch' non-existent in that revision
> >
> > $ svn ls file:///svn/repo/branch_at_4
> > trunk/
> >
> > To me this indicates that file:///svn/repo/branch only exists in
> > revision 4.
>
> The NAME only exists as of rev 4, but the file itself existed since rev
> one, under the name /trunk. This is confirmed by svn log, and svn ls or
> diff with -r1, which works.
>
> > $ svn ls -r1 file:///svn/repo/branch
> > trunk/
> >
> > Which is the same as:
> >
> > $ svn -r1 ls file:///svn/repo/branch_at_4
> > trunk/
>
> Please double check those as that should not be possible. An ls of the
> branch should not show that trunk is a subdirectory of the branch
> directory, ever, because trunk and branch are both peers in the root. I
> must assume here that you copied the results you stated last time of an
> ls on /repo, and just appended branch to the path without trying it.
>

No, I actually did try it. Please re-read your directions on setting
up the repository.
Your example starts with a checkout the root directory of the repos,
you create trunk and some files within truck, and then copy the WC to
/branch. That is what I did. Therefore you will get trunk as a
subdirectory of branch.

But that is immaterial to the discussion. We are both in agreement
that the contents of branch exist in revision 1 and that branch exists
in revision 4. We disagree about revs 2 and 3.

> > The SVN book states that in this case svn will find branch as it
> > exists in version 4 and trace it back through any renames until
> > revision 1.
>
> Exactly. The problem is that it can trace back to rev 1, but can not
> find it in rev 2 and 3. If it existed in rev 1, and was not deleted in
> rev 2 or 3, then logically it must still exist in rev 2 and 3.
>
> > $ svn -r2 ls file:///svn/repo/branch_at_4
> > svn: Unable to find repository location for 'file:///svn/repo/branch'
> > in revision 2
> >
> > This makes sense because branch is a copy of trunk version 1.
>
> It does not make sense because if it was a copy of rev 1, then it should
> still exist in rev 2, in a state that is unchanged from rev 1.
>
> > I disagree with this statement. I should only be able to retrieve the
> > state of a file at any revision where it exists. Branch only exists
> > in revisions 4 (when it was actually created) and 1 (because that is
> > the source of the copy).
>
> You have to notice the difference between the name, and the file. The
> NAME of branch was created in rev 4, but the FILE existed prior to
> that. If the FILE existed in rev 1, still exists in rev 4, then that
> file should exist in revs 2 and 3.
>
> Resolving the NAME of /branch can only be done in rev 4, since that is
> the point at which the name was created. This is why ls /branch@3 does
> not work; because in rev 3 that name was not there. Without the peg
> revision though, the name can be resolved in HEAD, and the file did
> exist as far back as rev 1, so logically it existed in all revs in
> between as well, even though it was not changed.
>

I do understand the difference and I understand what you are trying to
say. Personally I don't think it is an issue, sorry.

I did a little digging about this and there wasn't much to find except
this post:

http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=34782

Regardless of all that, please see my other post on how to perform the
merge. While you may think that it is sub-optimal it does work.

BTW, you may want to read up on the list about cp WC->URL
functionality. Apparently there are open bugs doing this that you may
want to know about.

:-)
Frodak

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 15 18:42:15 2007

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

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