Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Re: Merge problem: "path not found" error, SVN 1.5.5

subversion
Discussion topic

Hide all messages in topic

All messages in topic

Re: Merge problem: "path not found" error, SVN 1.5.5

Author mstrap
Full name Marc Strapetz
Date 2009-03-05 09:36:59 PST
Message >> Now, when checking out A at r32 and trying to perform following merge:
>>
>> svn merge http://host/B/dir2/file@33 -r33:29 ./dir/file
>>
>> it fails with:
>>
>> svn: File not found: revision 33, path '/A/dir/file'
>
> Hi Marc,
>
> What do you expect this merge to do (i.e. what is the use case)? You
> are trying to reverse merge the move of 'B/dir/file' to 'B/dir2/file'
> *directly* into 'A/dir/file'. So effectively you are trying to
> reverse merge the addition of a path (r30) directly onto a target
> path, which AFAICT has never been supported in Subversion.

Hello Paul,

Sorry for the confusion, I've "translated" the example from a real-world
problem, but didn't get it right -- anyway, the problem remains also for
 the correct translation:

  svn merge http://host/B/dir2/file@33 -r30:33 ./dir/file

So the revision range is 31-33 which *might* contain changes to
B/dir2/file. Let's assume r31 contains a change to B/dir2/file, then I
would expect to have this change merged onto my local ./dir/file (=
http://host/A/dir/file). But it fails with the given error message.

I think in general this problem isn't very likely, because when merging
my working copy is typically (almost) at HEAD. But this problem is
likely to occur when I'm going back to an earlier revision and
re-performing a merge. So due to this dependency on future revisions (my
WC is at r32, but SVN queries for WC URLs at r33), reproducibility of
merges is lost, once the merge has been committed.

--
Best regards,
Marc Strapetz
_____________
syntevo GmbH
www.syntevo.com



Paul Burba wrote:
> On Wed, Mar 4, 2009 at 7:08 AM, Marc Strapetz <marc.strapetz@sy​ntevo.com> wrote:
>> With SVN 1.5.5, for certain conditions merge code accesses "future"
>> target revisions and hence can fail with "path not found" error. Example
>> (maybe it's not minimal, but it's reproducible in this way for us):
>>
>> r29: A copied to B
>> r30: B/dir/file copied to B/dir2/file
>> B/dir/file removed
>> r31: ... non-relevant changes
>> r32: ... non-relevant changes
>> r33: Merged changes from B back to A,
>> especially A/dir/file gets removed.
>> r34: B removed
>>
>> Now, when checking out A at r32 and trying to perform following merge:
>>
>> svn merge http://host/B/dir2/file@33 -r33:29 ./dir/file
>>
>> it fails with:
>>
>> svn: File not found: revision 33, path '/A/dir/file'
>
> Hi Marc,
>
> What do you expect this merge to do (i.e. what is the use case)? You
> are trying to reverse merge the move of 'B/dir/file' to 'B/dir2/file'
> *directly* into 'A/dir/file'. So effectively you are trying to
> reverse merge the addition of a path (r30) directly onto a target
> path, which AFAICT has never been supported in Subversion.
>
> I agree the error is not very helpful and probably shouldn't occur at
> all. In 1.4.6 this is simply a no-op, is that what you were
> expecting?
>
> Paul
>
>> So, although I'm at r32 in my local working copy, svn tries to access
>> r33 of my (in repository already removed) working copy file and fails. I
>> think r33 shouldn't be accessed in this case and so far we figured out
>> that get_full_mergeinfo() in libsvn_client/merge.c:2424 is responsible
>> for that problem:
>>
>> /* Our underlying APIs can't yet handle the case where the peg
>> revision isn't the youngest of the three revisions. So we'll
>> just verify that the source in the peg revision is related to the
>> the source in the youngest requested revision (which is all the
>> underlying APIs would do in this case right now anyway). */
>> if (target_rev < start)
>> {
>> ...
>> SVN_ERR(svn_client__​repos_locations(​&start_url, &start_revision,
>> NULL, NULL, ra_session, url,
>> &pegrev, &requested,
>> &unspec, ctx, pool));
>> ...
>> }
>>
>> --
>> Best regards,
>> Marc Strapetz
>> _____________
>> syntevo GmbH
>> www.syntevo.com
>>
>> --------------------​--------------------​--------------
>> http://subversion.ti​gris.org/ds/viewMess​age.do?dsForumId=462​&dsMessageId=126​6499
>>
>
> --------------------​--------------------​--------------
> http://subversion.ti​gris.org/ds/viewMess​age.do?dsForumId=462​&dsMessageId=127​2583
>
>

Re: Merge problem: "path not found" error, SVN 1.5.5

Author Paul Burba <ptburba at gmail dot com>
Full name Paul Burba <ptburba at gmail dot com>
Date 2009-03-05 07:37:29 PST
Message On Wed, Mar 4, 2009 at 7:08 AM, Marc Strapetz <marc.strapetz@sy​ntevo.com> wrote:
> With SVN 1.5.5, for certain conditions merge code accesses "future"
> target revisions and hence can fail with "path not found" error. Example
> (maybe it's not minimal, but it's reproducible in this way for us):
>
> r29: A copied to B
> r30: B/dir/file copied to B/dir2/file
>     B/dir/file removed
> r31: ... non-relevant changes
> r32: ... non-relevant changes
> r33: Merged changes from B back to A,
>     especially A/dir/file gets removed.
> r34: B removed
>
> Now, when checking out A at r32 and trying to perform following merge:
>
>  svn merge http://host/B/dir2/file@33 -r33:29 ./dir/file
>
> it fails with:
>
>  svn: File not found: revision 33, path '/A/dir/file'

Hi Marc,

What do you expect this merge to do (i.e. what is the use case)? You
are trying to reverse merge the move of 'B/dir/file' to 'B/dir2/file'
*directly* into 'A/dir/file'. So effectively you are trying to
reverse merge the addition of a path (r30) directly onto a target
path, which AFAICT has never been supported in Subversion.

I agree the error is not very helpful and probably shouldn't occur at
all. In 1.4.6 this is simply a no-op, is that what you were
expecting?

Paul

> So, although I'm at r32 in my local working copy, svn tries to access
> r33 of my (in repository already removed) working copy file and fails. I
> think r33 shouldn't be accessed in this case and so far we figured out
> that get_full_mergeinfo() in libsvn_client/merge.c:2424 is responsible
> for that problem:
>
>  /* Our underlying APIs can't yet handle the case where the peg
>     revision isn't the youngest of the three revisions.  So we'll
>     just verify that the source in the peg revision is related to the
>     the source in the youngest requested revision (which is all the
>     underlying APIs would do in this case right now anyway). */
>  if (target_rev < start)
>    {
>     ...
>      SVN_ERR(svn_client_​_repos_locations(​&start_url, &start_revision,
>                                          NULL, NULL, ra_session, url,
>                                          &pegrev, &requested,
>                                          &unspec, ctx, pool));
>     ...
>    }
>
> --
> Best regards,
> Marc Strapetz
> _____________
> syntevo GmbH
> www.syntevo.com
>
> --------------------​--------------------​--------------
> http://subversion.ti​gris.org/ds/viewMess​age.do?dsForumId=462​&dsMessageId=126​6499
>

Merge problem: "path not found" error, SVN 1.5.5

Author mstrap
Full name Marc Strapetz
Date 2009-03-04 04:08:58 PST
Message With SVN 1.5.5, for certain conditions merge code accesses "future"
target revisions and hence can fail with "path not found" error. Example
(maybe it's not minimal, but it's reproducible in this way for us):

r29: A copied to B
r30: B/dir/file copied to B/dir2/file
     B/dir/file removed
r31: ... non-relevant changes
r32: ... non-relevant changes
r33: Merged changes from B back to A,
     especially A/dir/file gets removed.
r34: B removed

Now, when checking out A at r32 and trying to perform following merge:

  svn merge http://host/B/dir2/file@33 -r33:29 ./dir/file

it fails with:

  svn: File not found: revision 33, path '/A/dir/file'

So, although I'm at r32 in my local working copy, svn tries to access
r33 of my (in repository already removed) working copy file and fails. I
think r33 shouldn't be accessed in this case and so far we figured out
that get_full_mergeinfo() in libsvn_client/merge.c:2424 is responsible
for that problem:

  /* Our underlying APIs can't yet handle the case where the peg
     revision isn't the youngest of the three revisions. So we'll
     just verify that the source in the peg revision is related to the
     the source in the youngest requested revision (which is all the
     underlying APIs would do in this case right now anyway). */
  if (target_rev < start)
    {
     ...
      SVN_ERR(svn_client__​repos_locations(​&start_url, &start_revision,
                                          NULL, NULL, ra_session, url,
                                          &pegrev, &requested,
                                          &unspec, ctx, pool));
     ...
    }

--
Best regards,
Marc Strapetz
_____________
syntevo GmbH
www.syntevo.com
Messages per page: