On Mar 2, 2005, at 9:36 AM, Robin Becker wrote:
>
> users\chris doesn't seem to be in the branch, but was created in the
> trunk at
> 14331 as an empty folder.
Understood.
> The main branch changes
> r13172 copied from trunk
> r15350 merged trunk 13312:15349 should have created users chris, but
> didn't.
Why did you merge starting at r13312, rather than r13172? Unless
absolutely nothing happened on the trunk between those two revisions,
this might cause unclean merges later on.
In any case, you're right... if the 'chris' directory came into
existence on the trunk in r14331, then 'svn merge -r13312:15349' should
definitely have created it. And I suspect it was created, but then
something happened to it later on. Maybe some other branch change
accidentally removed it?
Two things you can do to investigate/verify that the original merge
worked as it should have:
1. 'svn log -v -r15350' Look at the list of changed files. You should
see a line showing that 'users\chris' was added to the branch.
2. replay the whole scenario. Checkout r15349 of the branch, then try
merging -r13312:15349 of trunk into the working copy. See what
happens.
> r15771 15350:15769 Presumably some changes were skipped here
Well, you should have started with 15349, not 15350. 'svn merge'
always compares 2 tree snapshots, so as a rule, you always want your
start-revision to be the same as the previous end-revision:
svn merge -rA:B trunkURL
svn merge -rB:C trunkURL
svn merge -rC:D trunkURL
[...]
...otherwise you risk skipping a commit's worth of changes. I have no
idea in this case, though, if r15350 was important.
>
> I suppose that svn is incapable of making up a container if it isn't
> present.
Correct. For example, if the two trees being compared both contain
'users\chris\foo.txt', and the right-hand tree has different
file-contents for foo.txt, then the merge process will attempt to patch
'users\chris\foo.txt' in the working copy. If the path doesn't
exist... or if some parent doesn't exist... the path won't be created.
Instead, merge just treats this like a "failed hunk". You should see
"skipped" messages.
> Even so shouldn't it just skip changes it cannot apply?
>
Definitely. The 'not locked' message is some sort of bug. Is there
any way one of the developers can hit your repository and try to
reproduce the error? Then we could step through the client in gdb and
see what's going on. Or is the data too sensitive?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 2 23:47:57 2005