On Mon, Jan 26, 2009 at 6:39 PM, Brian Rieck <BRieck_at_sandcherry.com> wrote:
> Thanks Paul,
>
> I get no output from the svn propget svn:mergeinfo for any of those urls.
>
> Yes, actually the no-op was intentional but it produced the error. I was trying to reproduce the problem that a user was seeing on the production server and had a list of things that he thought he had done, all of which looked benign to me. I wanted to try a merge after each possibility to see what might reproduce the problem. I was surprised to see it happen right away; I fully expected a no-op.
>
> Wow, the 'svn log -vq' command, even on one file was huge! I guess it contains info about all the files committees at the same time for each rev. This will include 50,000+ files for the intial import though. Parsing it was looking pretty tough. I was able though with just a "normal" log command to find the revision where a file was moved from one location to another. I then did the diff as requested and did see:
>
> Added: svn:mergeinfo
Brian,
It's worth noting that 1.5.5 no longer creates this empty mergeinfo.
This doesn't solve your immediate problem, in fact I'm not even sure
they are related, but still, I'd suggest using 1.5.5 if at all
possible (it should also address some other problems you have - see
below).
> Yep, I can successfully do a merge at any level other than the root all the way down to the problem directory. Here is some info from my original long winded post:
>
> *******************
>
> I have isolated the problem to a specific directory fairly deep in the tree. Interestingly enough if I do a merge of just that directory or *any of its parents except* the very top level of the tree it works. After doing that merge I can then successfully merge the entire tree.
>
> I get no output from the "svn propget svn:mergeinfo" command on the problem directory in either branch. (I tried verbose as suggested but propget doesn't seem to allow for a verbose flag)
>
> The diff of the problem directory after merging just the problem directory (which seems to solve the problem):
>
> ******************************
> Property changes on: platform\packagingdistribution\Vivo Applications\vmc\WebContent
^
Is this right? Where is the path separator?
> ___________________________________________________________________
> Modified: svn:mergeinfo
> Merged /branches/4.1.00_Dev/platform/packaging/distribution/Vivo Applications/vmc/WebContent:r3-373
> Merged /branches/user_branches/camille/platform/packaging/distribution/Vivo Applications/vmc/WebContent:r704
Could you provide the exact command and output of this successful
merge to 'platform\packagingdistribution\Vivo
Applications\vmc\WebContent'?
Since both 'camille\platform\packaging\distribution\Vivo
Applications\vmc\WebContent' and
'jeff3\platform\packaging\distribution\Vivo
Applications\vmc\WebContent' have empty mergeinfo I'm curious where
the mergeinfo that is set on the target is coming from. I hope that
the merge output notifications might shed some light on this -- if
there are any notifications that is, this should be a no-op and I'd
expect the only mergeinfo set to be the single revision from
'/branches/user_branches/camille/platform/packaging/distribution/Vivo
Applications/vmc/WebContent' that corresponded to the revision created
with '5) svn cp <url_to_repo>/branches/user_branches/Camille
<url_to_repo>/branches/user_branches/Jeff3'.
> ******************************
>
> btw - This is probably unrelated but I am also receiving a fair number of complaints about "Working copy path "<path> "does not exist in repository" errors while merging
What version of svn do your users use? This error is typically
associated with a rather notorious (to me anyway) set of bugs
described here:
http://subversion.tigris.org/issues/show_bug.cgi?id=3067. All known
problems related to this issue were fixed in 1.5.5, so that is another
reason to use 1.5.5 (at least as your client, since all the fixes are
on the client side).
If you still get the following error when merging with a 1.5.5 client,
"svn: Working copy path 'some_path' does not exist in repository",
then please submit a separate bug report to the dev list.
> and "Working copy" <path> "locked" errors while people are trying to merge from parent to child branches. I think the Working copy locked" problem was because of a move that did nothing but change the case of a folder name.
Case only renames have always been problematic when your WC is on a
case-insensitive file system:
http://subversion.tigris.org/issues/show_bug.cgi?id=3115
http://subversion.tigris.org/issues/show_bug.cgi?id=667
http://subversion.tigris.org/issues/show_bug.cgi?id=1495
http://subversion.tigris.org/issues/show_bug.cgi?id=2010
> We seem to have been able to work around these problems through a combination of deleting working copies before merging. I have been assuming that these problems are unrelated to the one at hand but thought I'd bring it up.
At first glance I can't see how either of these could be related to
the parsing problem, but I'll keep them in mind.
> Since this is a test server I can do anything to it without ramifications, including blowing away the repo and bringing it back from a backup of the production repo. So if there is anything you want me to do at all I can do it. If you would like I can redo my steps but capture the output to a file. You would probably want me to either surpress the initial co output as it will be long. Just let me know. If I do that would it be acceptable to include it as an attachment or would it be preferred on the mailing list to include the output in the mail message?
Using svn <= 1.5.5 could you run 'svn pg svn:mergeinfo -R' on the root
of the repository prior to '7) svn merge <url_to_new_camille_branch>
<wc_path_to_jeff3>'?
If there is any mergeinfo in the repository with reversed ranges then
you'd get an 'Unable to parse reversed revision range' error. I'm
grasping here, but I want to see if there is *any* explicit mergeinfo
anywhere in the repository with reversed revision ranges. To get the
'Unable to parse reversed revision range' error there *must* be a
string representation of invalid svn:mergeinfo somewhere. If there is
no such mergeinfo already set on a path in the repos, then it must be
created to describe the merge.
> I really appreciate your help.
>
> -Brian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1059387
Received on 2009-01-27 17:10:39 CET