On 2/16/07, Phillip Susi <psusi@cfl.rr.com> wrote:
> 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.
Thinking about this more, you almost never want the behavior you describe.
For instance, lets say you have file foo in r10, delete it in r11, and then:
svn cp -r10 file:///repo/trunk/foo file:///repo/trunk to restore it in r14.
When you perform the ls, cp, diff, etc commands, for versions 11, 12,
13 you want it to say it does not exist in those versions.
Then in r15 you delete the file again and then in r17 you restore
version 10 again:
svn cp -r10 file:///repo/trunk/foo file:///repo/trunk
What should the command log -r14 file:///repo/trunk/foo return?
It should return that it could not find the object in r14, because r14
object is from a different line of history then the HEAD object.
As of now, SVN seems to be fairly consistent, an object does not exist
between the version it was copied from and the version it was copied
to.
I.E
$ svn log file_1.txt -v
------------------------------------------------------------------------
r18 | fbaksik | 2007-02-17 08:58:02 -0500 (Sat, 17 Feb 2007) | 1 line
Changed paths:
A /trunk/main/file_1.txt (from /trunk/main/file_1.txt:13)
Restore file again.
Any reference, of r14 to r17 (inclusive), will return an object not
found type of error.
What you are asking for is to break this simple rule and say, if the
object I copy from is a different path than what I copy to, then say
the object does exist! But even this is not a hard and fast rule
because if you folder renames the same time you do add or deletes,
it'll look like you are copying from a different path when you're not.
Personally, I vote keep it simple.
:-)
Frodak
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 17 15:26:15 2007