Jeff Smith wrote:
> Phillip,
>
> It makes sense to me that the merge should be starting from the
> "copy-from" rev and not from the "copy-to" rev minus one. (it means
> Frodak makes sense)
>
> I was confused when learning subversion because each rev is global to
> the entire tree. What I learned, which might help visualize this
> merge issue, is that the changes in a diff come from a combination of
> the range (i.e. -r1:4) *and* the path given.
Forget about merging. The issue is that a file exists in rev 1, and in
rev 4, but magically does not exist in 2 and 3. It does not make sense
for a file to be created, then no longer exist for a while, then pop
back up again. In any other case if the log shows that a file was
created in rev 1 and modified in rev 4, then it existed in 2 and 3 as
well.
> What I mean is that I would have been afraid that rev 2 & 3 would have
> somehow messed up your merge if included in the range, but it does
> not because those revisions had nothing to do with your branch.
>
> Since you were looking the revisions specifically related to the
> combination -r3 and your branch path {i.e. svn log
> -r3:4 /repo/branch}, naturally those were not found because that path
> was not in rev 3.
The PATH is found in the HEAD revision because a peg revision was not
used to change that. Once the path has been resolved, the file's
history shows that it was created in rev 1, yet an attempt to access
it's state in rev 2 fails. There is a big difference between svn ls
/repo/branch@3 and svn ls -r3 /repo/branch. The former fails for the
reason you mention, the latter should not. Notice how -r1 works even
though branch did not exist with that name in r1 either, but it DID exist.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 16 16:56:09 2007