On 1/8/07, Ryan Schmidt <subversion-2007a@ryandesign.com> wrote:
>
> > During my searches of the mailing list someone had a similar error
> > message and was able to get around it by issuing the svn up command
> > on the trunk so I tried to do that and go this error message:
> >
> > svn up
> >
> > svn: REPORT request failed on '/repos/intranet/!svn/vcc/default'
> > svn: Working copy path 'sendnewsletter.php' does not exist in
> > repository
> >
> > I am not exactly sure where to go from here so if someone could
> > advise me I would really appreciate it. The only thing that I
> > could about that would make this file any different than any other
> > file I have committed so far as I believe this file was deleted in
> > the repository and then a different file with the same filename was
> > added. Not too sure if that would make a difference or not.
>
> Yes, it sounds like, after revision 86, in the release-1.2.0 branch,
> sendnewsletter.php was deleted and then another file of the same name
> was added. Also, after revision 86, in trunk, sendnewsletter.php was
> modified, I think.
>
> Your working copy is of trunk revision 86, plus local changes (merged
> from the release-1.2.0 branch) which include deleting
> sendnewsletter.php and recreating it. The version of
> sendnewsletter.php in your working copy is therefore not linked with
> the one that was in the trunk before. Therefore (apparently) you
> can't get its log. Try querying the repository by URL. If you want
> the log of the item that was in the trunk:
>
> svn log http://svn.hddbroker.com/repos/intranet/trunk/website/
> mailinglist/sendnewsletter.php
>
> If you want the log of the item in the release-1.2.0 branch:
>
> svn log http://svn.hddbroker.com/repos/intranet/branches/
> release-1.2.0/website/mailinglist/sendnewsletter.php
>
> (My email client will probably destroy those long URLs. Sorry; please
> recombine them by hand if necessary.)
>
> The reason you cannot update the working copy now seems to be that
> Subversion wants to provide you with changes to sendnewsletter.php
> which occurred on trunk between r86 and HEAD, but the object to which
> it wants to apply those changes no longer exists (it was deleted by
> the merge).
>
>
> Perhaps someone else can explain how to get out of this situation
> now, and how to avoid it in the future, as I'm unclear on these points.
I would guess that if he did a checkout of HEAD and then did merge with the
--ignore-ancestry option, that it would work and he could then commit.
Without --ignore-ancestry, merge is not going to merge that file.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Mon Jan 8 22:53:30 2007