You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Ferguson <fe...@gmail.com> on 2008/10/30 14:04:41 UTC
BUG? Merging from foreign repository corrupts UUID
I've found that when merging from a foreign repository, Subversion will
corrupt the UUID of any file being added in the merge.
Here is a short series of commands to create the situation:
# Create the first repository
$ svnadmin create repo1
$ svn co file:///home/dferguso/breakage/repo1 work1
# Add a file to the first repository
$ touch work1/new_file
$ svn add work1/new_file
$ svn ci work1 -m "added a file"
# Create the second repository
$ svnadmin create repo2
$ svn co file:///home/dferguso/breakage/repo2 work2
# Merge change #1 from the first repository to the second
$ svn merge file:///home/dferguso/breakage/repo1 -c1 work2
# Check info. UUID on work2 and work2/new_file don't match!!
$ svn info work1 work2 work2/new_file
Notice that the UUID of work2/new_file is from repository #1 !! It should
match the UUID of its parent directory, work2. This leaves the work2
directory in a bad state. Things like switch and update start complaining
that the UUID of the WC doesn't match the repository.
svn: The repository at '<full url>' has uuid 'XYZ', but the WC has 'ABC'
The only fix is to recheckout the work directory. Can someone else confirm
that this is a problem? Or is this an already-known issue? (I didn't see
anything in the issue tracker.)
Subversion client is 1.5.3, Linux x86_64, RHEL 4, update 6.
thanks,
David
Re: BUG? Merging from foreign repository corrupts UUID
Posted by John Szakmeister <jo...@szakmeister.net>.
On Tue, Nov 4, 2008 at 7:52 AM, C. Michael Pilato <cm...@collab.net> wrote:
> John Szakmeister wrote:
>> On Thu, Oct 30, 2008 at 10:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> David Ferguson wrote on Thu, 30 Oct 2008 at 10:47 -0400:
>>>> Daniel,
>>>>
>>>> Thanks for confirming the problem even with the trunk build. I'll post this
>>>> to dev@subversion then.
>>>>
>>> If I saw here, the other devs will see it too. :) But in the meantime,
>>> I looked into the code (libsvn_client/merge.c) and couldn't find how the
>>> other repository's UUID is even transferred to the wc layer, so another
>>> eye on this would be appreciated.
>>
>> I can't see where this happening either. I think I've narrowed it
>> down to a couple of WC functions but it's still unclear to me how it
>> gets there in the first place.
>
> I know where this happens. See attached patch which, I think, fixes the
> problem.
Sweet. And I see the fix was checked in.
>> I've attached a patch the adds a test to the test_suite. I'd
>> appreciate feedback on it Daniel. If it looks good, we can at least
>> get the test in and figure out how to solve the real problem.
>>
>> -John
>>
>> ======================
>> Add a test for checking the uuid of a file merged from a foreign repository.
>>
>> * subversion/tests/cmdline/merge_tests.py
>> (foreign_repos_uuid): New.
>>
>> (test_list): Add foreign_repos_uuid as XFAIL.
>
> Thanks for the test. Only problem is that in the *correct* behavior case
> (where the foreign merged add becomes just an add), 'svn info' want show the
> "Repository UUID" line in the output at all. This causes your test to choke.
Doh! I'm actually a little surprised by that. I would have thought
the entries would have been empty for the UUID field as so it would
inherit thisdir's UUID. There must be some logic restricting that
output for added files.
Looks like you tweaked the test and verified it after the fact. Cool,
and glad I could help!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG? Merging from foreign repository corrupts UUID
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Yes (there is a chance), since the relevant patches are already in
1.5.x/STATUS and have two +1 votes.
Thanks for the bug,
Daniel
David Ferguson wrote on Tue, 4 Nov 2008 at 17:42 -0500:
> Guys, thanks for addressing this so quickly. I saw that the fixes were
> checked into the trunk. Any chance that this fix will make it into the next
> 1.5.x release?
>
> thanks,
> David
>
>
>
> On Tue, Nov 4, 2008 at 3:34 PM, C. Michael Pilato <cm...@collab.net>wrote:
>
> > Daniel Shahaf wrote:
> > > C. Michael Pilato wrote on Tue, 4 Nov 2008 at 07:52 -0500:
> > >> John Szakmeister wrote:
> > >>> I can't see where this happening either. I think I've narrowed it
> > >>> down to a couple of WC functions but it's still unclear to me how it
> > >>> gets there in the first place.
> > >> I know where this happens. See attached patch which, I think, fixes the
> > >> problem.
> > >>
> > >>> I've attached a patch the adds a test to the test_suite. I'd
> > >>> appreciate feedback on it Daniel. If it looks good, we can at least
> > >>> get the test in and figure out how to solve the real problem.
> > >>>
> > >
> > > Looks good, modulo:
> > >
> > > * doc string is over 50 characters
> > >
> > > * you can use the new run_and_verify_info() / get_wc_uuid() functions
> > > instead of parsing stdout_lines yourself.
> > >
> > >>> -John
> > >>>
> > >>> ======================
> > >>> Add a test for checking the uuid of a file merged from a foreign
> > repository.
> > >>>
> > >>> * subversion/tests/cmdline/merge_tests.py
> > >>> (foreign_repos_uuid): New.
> > >>>
> > >>> (test_list): Add foreign_repos_uuid as XFAIL.
> > >> Thanks for the test. Only problem is that in the *correct* behavior
> > case
> > >> (where the foreign merged add becomes just an add), 'svn info' want show
> > the
> > >> "Repository UUID" line in the output at all. This causes your test to
> > choke.
> > >>
> > >
> > > Good point. If we're paranoid we could modify the test to do a commit
> > and
> > > double-check the UUIDs after the commit (I've said upthread that the
> > UUIDs
> > > remain inconsistent even after the foreign-merge-of-add is committed).
> >
> > r34050,-51.
> >
> > I went the route of checking the UUID after commit (and using
> > run_and_verify_info, per your suggestion).
> >
> > --
> > C. Michael Pilato <cm...@collab.net>
> > CollabNet <> www.collab.net <> Distributed Development On Demand
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG? Merging from foreign repository corrupts UUID
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Yes (there is a chance), since the relevant patches are already in
1.5.x/STATUS and have two +1 votes.
Thanks for the bug,
Daniel
David Ferguson wrote on Tue, 4 Nov 2008 at 17:42 -0500:
> Guys, thanks for addressing this so quickly. I saw that the fixes were
> checked into the trunk. Any chance that this fix will make it into the next
> 1.5.x release?
>
> thanks,
> David
>
>
>
> On Tue, Nov 4, 2008 at 3:34 PM, C. Michael Pilato <cm...@collab.net>wrote:
>
> > Daniel Shahaf wrote:
> > > C. Michael Pilato wrote on Tue, 4 Nov 2008 at 07:52 -0500:
> > >> John Szakmeister wrote:
> > >>> I can't see where this happening either. I think I've narrowed it
> > >>> down to a couple of WC functions but it's still unclear to me how it
> > >>> gets there in the first place.
> > >> I know where this happens. See attached patch which, I think, fixes the
> > >> problem.
> > >>
> > >>> I've attached a patch the adds a test to the test_suite. I'd
> > >>> appreciate feedback on it Daniel. If it looks good, we can at least
> > >>> get the test in and figure out how to solve the real problem.
> > >>>
> > >
> > > Looks good, modulo:
> > >
> > > * doc string is over 50 characters
> > >
> > > * you can use the new run_and_verify_info() / get_wc_uuid() functions
> > > instead of parsing stdout_lines yourself.
> > >
> > >>> -John
> > >>>
> > >>> ======================
> > >>> Add a test for checking the uuid of a file merged from a foreign
> > repository.
> > >>>
> > >>> * subversion/tests/cmdline/merge_tests.py
> > >>> (foreign_repos_uuid): New.
> > >>>
> > >>> (test_list): Add foreign_repos_uuid as XFAIL.
> > >> Thanks for the test. Only problem is that in the *correct* behavior
> > case
> > >> (where the foreign merged add becomes just an add), 'svn info' want show
> > the
> > >> "Repository UUID" line in the output at all. This causes your test to
> > choke.
> > >>
> > >
> > > Good point. If we're paranoid we could modify the test to do a commit
> > and
> > > double-check the UUIDs after the commit (I've said upthread that the
> > UUIDs
> > > remain inconsistent even after the foreign-merge-of-add is committed).
> >
> > r34050,-51.
> >
> > I went the route of checking the UUID after commit (and using
> > run_and_verify_info, per your suggestion).
> >
> > --
> > C. Michael Pilato <cm...@collab.net>
> > CollabNet <> www.collab.net <> Distributed Development On Demand
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: BUG? Merging from foreign repository corrupts UUID
Posted by David Ferguson <fe...@gmail.com>.
Guys, thanks for addressing this so quickly. I saw that the fixes were
checked into the trunk. Any chance that this fix will make it into the next
1.5.x release?
thanks,
David
On Tue, Nov 4, 2008 at 3:34 PM, C. Michael Pilato <cm...@collab.net>wrote:
> Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Tue, 4 Nov 2008 at 07:52 -0500:
> >> John Szakmeister wrote:
> >>> I can't see where this happening either. I think I've narrowed it
> >>> down to a couple of WC functions but it's still unclear to me how it
> >>> gets there in the first place.
> >> I know where this happens. See attached patch which, I think, fixes the
> >> problem.
> >>
> >>> I've attached a patch the adds a test to the test_suite. I'd
> >>> appreciate feedback on it Daniel. If it looks good, we can at least
> >>> get the test in and figure out how to solve the real problem.
> >>>
> >
> > Looks good, modulo:
> >
> > * doc string is over 50 characters
> >
> > * you can use the new run_and_verify_info() / get_wc_uuid() functions
> > instead of parsing stdout_lines yourself.
> >
> >>> -John
> >>>
> >>> ======================
> >>> Add a test for checking the uuid of a file merged from a foreign
> repository.
> >>>
> >>> * subversion/tests/cmdline/merge_tests.py
> >>> (foreign_repos_uuid): New.
> >>>
> >>> (test_list): Add foreign_repos_uuid as XFAIL.
> >> Thanks for the test. Only problem is that in the *correct* behavior
> case
> >> (where the foreign merged add becomes just an add), 'svn info' want show
> the
> >> "Repository UUID" line in the output at all. This causes your test to
> choke.
> >>
> >
> > Good point. If we're paranoid we could modify the test to do a commit
> and
> > double-check the UUIDs after the commit (I've said upthread that the
> UUIDs
> > remain inconsistent even after the foreign-merge-of-add is committed).
>
> r34050,-51.
>
> I went the route of checking the UUID after commit (and using
> run_and_verify_info, per your suggestion).
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
Re: BUG? Merging from foreign repository corrupts UUID
Posted by David Ferguson <fe...@gmail.com>.
Guys, thanks for addressing this so quickly. I saw that the fixes were
checked into the trunk. Any chance that this fix will make it into the next
1.5.x release?
thanks,
David
On Tue, Nov 4, 2008 at 3:34 PM, C. Michael Pilato <cm...@collab.net>wrote:
> Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Tue, 4 Nov 2008 at 07:52 -0500:
> >> John Szakmeister wrote:
> >>> I can't see where this happening either. I think I've narrowed it
> >>> down to a couple of WC functions but it's still unclear to me how it
> >>> gets there in the first place.
> >> I know where this happens. See attached patch which, I think, fixes the
> >> problem.
> >>
> >>> I've attached a patch the adds a test to the test_suite. I'd
> >>> appreciate feedback on it Daniel. If it looks good, we can at least
> >>> get the test in and figure out how to solve the real problem.
> >>>
> >
> > Looks good, modulo:
> >
> > * doc string is over 50 characters
> >
> > * you can use the new run_and_verify_info() / get_wc_uuid() functions
> > instead of parsing stdout_lines yourself.
> >
> >>> -John
> >>>
> >>> ======================
> >>> Add a test for checking the uuid of a file merged from a foreign
> repository.
> >>>
> >>> * subversion/tests/cmdline/merge_tests.py
> >>> (foreign_repos_uuid): New.
> >>>
> >>> (test_list): Add foreign_repos_uuid as XFAIL.
> >> Thanks for the test. Only problem is that in the *correct* behavior
> case
> >> (where the foreign merged add becomes just an add), 'svn info' want show
> the
> >> "Repository UUID" line in the output at all. This causes your test to
> choke.
> >>
> >
> > Good point. If we're paranoid we could modify the test to do a commit
> and
> > double-check the UUIDs after the commit (I've said upthread that the
> UUIDs
> > remain inconsistent even after the foreign-merge-of-add is committed).
>
> r34050,-51.
>
> I went the route of checking the UUID after commit (and using
> run_and_verify_info, per your suggestion).
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
Re: BUG? Merging from foreign repository corrupts UUID
Posted by "C. Michael Pilato" <cm...@collab.net>.
Daniel Shahaf wrote:
> C. Michael Pilato wrote on Tue, 4 Nov 2008 at 07:52 -0500:
>> John Szakmeister wrote:
>>> I can't see where this happening either. I think I've narrowed it
>>> down to a couple of WC functions but it's still unclear to me how it
>>> gets there in the first place.
>> I know where this happens. See attached patch which, I think, fixes the
>> problem.
>>
>>> I've attached a patch the adds a test to the test_suite. I'd
>>> appreciate feedback on it Daniel. If it looks good, we can at least
>>> get the test in and figure out how to solve the real problem.
>>>
>
> Looks good, modulo:
>
> * doc string is over 50 characters
>
> * you can use the new run_and_verify_info() / get_wc_uuid() functions
> instead of parsing stdout_lines yourself.
>
>>> -John
>>>
>>> ======================
>>> Add a test for checking the uuid of a file merged from a foreign repository.
>>>
>>> * subversion/tests/cmdline/merge_tests.py
>>> (foreign_repos_uuid): New.
>>>
>>> (test_list): Add foreign_repos_uuid as XFAIL.
>> Thanks for the test. Only problem is that in the *correct* behavior case
>> (where the foreign merged add becomes just an add), 'svn info' want show the
>> "Repository UUID" line in the output at all. This causes your test to choke.
>>
>
> Good point. If we're paranoid we could modify the test to do a commit and
> double-check the UUIDs after the commit (I've said upthread that the UUIDs
> remain inconsistent even after the foreign-merge-of-add is committed).
r34050,-51.
I went the route of checking the UUID after commit (and using
run_and_verify_info, per your suggestion).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: BUG? Merging from foreign repository corrupts UUID
Posted by "C. Michael Pilato" <cm...@collab.net>.
Daniel Shahaf wrote:
> C. Michael Pilato wrote on Tue, 4 Nov 2008 at 07:52 -0500:
>> John Szakmeister wrote:
>>> I can't see where this happening either. I think I've narrowed it
>>> down to a couple of WC functions but it's still unclear to me how it
>>> gets there in the first place.
>> I know where this happens. See attached patch which, I think, fixes the
>> problem.
>>
>>> I've attached a patch the adds a test to the test_suite. I'd
>>> appreciate feedback on it Daniel. If it looks good, we can at least
>>> get the test in and figure out how to solve the real problem.
>>>
>
> Looks good, modulo:
>
> * doc string is over 50 characters
>
> * you can use the new run_and_verify_info() / get_wc_uuid() functions
> instead of parsing stdout_lines yourself.
>
>>> -John
>>>
>>> ======================
>>> Add a test for checking the uuid of a file merged from a foreign repository.
>>>
>>> * subversion/tests/cmdline/merge_tests.py
>>> (foreign_repos_uuid): New.
>>>
>>> (test_list): Add foreign_repos_uuid as XFAIL.
>> Thanks for the test. Only problem is that in the *correct* behavior case
>> (where the foreign merged add becomes just an add), 'svn info' want show the
>> "Repository UUID" line in the output at all. This causes your test to choke.
>>
>
> Good point. If we're paranoid we could modify the test to do a commit and
> double-check the UUIDs after the commit (I've said upthread that the UUIDs
> remain inconsistent even after the foreign-merge-of-add is committed).
r34050,-51.
I went the route of checking the UUID after commit (and using
run_and_verify_info, per your suggestion).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: BUG? Merging from foreign repository corrupts UUID
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Tue, 4 Nov 2008 at 07:52 -0500:
> John Szakmeister wrote:
> > I can't see where this happening either. I think I've narrowed it
> > down to a couple of WC functions but it's still unclear to me how it
> > gets there in the first place.
>
> I know where this happens. See attached patch which, I think, fixes the
> problem.
>
> > I've attached a patch the adds a test to the test_suite. I'd
> > appreciate feedback on it Daniel. If it looks good, we can at least
> > get the test in and figure out how to solve the real problem.
> >
Looks good, modulo:
* doc string is over 50 characters
* you can use the new run_and_verify_info() / get_wc_uuid() functions
instead of parsing stdout_lines yourself.
> > -John
> >
> > ======================
> > Add a test for checking the uuid of a file merged from a foreign repository.
> >
> > * subversion/tests/cmdline/merge_tests.py
> > (foreign_repos_uuid): New.
> >
> > (test_list): Add foreign_repos_uuid as XFAIL.
>
> Thanks for the test. Only problem is that in the *correct* behavior case
> (where the foreign merged add becomes just an add), 'svn info' want show the
> "Repository UUID" line in the output at all. This causes your test to choke.
>
Good point. If we're paranoid we could modify the test to do a commit and
double-check the UUIDs after the commit (I've said upthread that the UUIDs
remain inconsistent even after the foreign-merge-of-add is committed).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG? Merging from foreign repository corrupts UUID
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Tue, 4 Nov 2008 at 07:52 -0500:
> John Szakmeister wrote:
> > I can't see where this happening either. I think I've narrowed it
> > down to a couple of WC functions but it's still unclear to me how it
> > gets there in the first place.
>
> I know where this happens. See attached patch which, I think, fixes the
> problem.
>
> > I've attached a patch the adds a test to the test_suite. I'd
> > appreciate feedback on it Daniel. If it looks good, we can at least
> > get the test in and figure out how to solve the real problem.
> >
Looks good, modulo:
* doc string is over 50 characters
* you can use the new run_and_verify_info() / get_wc_uuid() functions
instead of parsing stdout_lines yourself.
> > -John
> >
> > ======================
> > Add a test for checking the uuid of a file merged from a foreign repository.
> >
> > * subversion/tests/cmdline/merge_tests.py
> > (foreign_repos_uuid): New.
> >
> > (test_list): Add foreign_repos_uuid as XFAIL.
>
> Thanks for the test. Only problem is that in the *correct* behavior case
> (where the foreign merged add becomes just an add), 'svn info' want show the
> "Repository UUID" line in the output at all. This causes your test to choke.
>
Good point. If we're paranoid we could modify the test to do a commit and
double-check the UUIDs after the commit (I've said upthread that the UUIDs
remain inconsistent even after the foreign-merge-of-add is committed).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: BUG? Merging from foreign repository corrupts UUID
Posted by John Szakmeister <jo...@szakmeister.net>.
On Tue, Nov 4, 2008 at 7:52 AM, C. Michael Pilato <cm...@collab.net> wrote:
> John Szakmeister wrote:
>> On Thu, Oct 30, 2008 at 10:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> David Ferguson wrote on Thu, 30 Oct 2008 at 10:47 -0400:
>>>> Daniel,
>>>>
>>>> Thanks for confirming the problem even with the trunk build. I'll post this
>>>> to dev@subversion then.
>>>>
>>> If I saw here, the other devs will see it too. :) But in the meantime,
>>> I looked into the code (libsvn_client/merge.c) and couldn't find how the
>>> other repository's UUID is even transferred to the wc layer, so another
>>> eye on this would be appreciated.
>>
>> I can't see where this happening either. I think I've narrowed it
>> down to a couple of WC functions but it's still unclear to me how it
>> gets there in the first place.
>
> I know where this happens. See attached patch which, I think, fixes the
> problem.
Sweet. And I see the fix was checked in.
>> I've attached a patch the adds a test to the test_suite. I'd
>> appreciate feedback on it Daniel. If it looks good, we can at least
>> get the test in and figure out how to solve the real problem.
>>
>> -John
>>
>> ======================
>> Add a test for checking the uuid of a file merged from a foreign repository.
>>
>> * subversion/tests/cmdline/merge_tests.py
>> (foreign_repos_uuid): New.
>>
>> (test_list): Add foreign_repos_uuid as XFAIL.
>
> Thanks for the test. Only problem is that in the *correct* behavior case
> (where the foreign merged add becomes just an add), 'svn info' want show the
> "Repository UUID" line in the output at all. This causes your test to choke.
Doh! I'm actually a little surprised by that. I would have thought
the entries would have been empty for the UUID field as so it would
inherit thisdir's UUID. There must be some logic restricting that
output for added files.
Looks like you tweaked the test and verified it after the fact. Cool,
and glad I could help!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: BUG? Merging from foreign repository corrupts UUID
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Szakmeister wrote:
> On Thu, Oct 30, 2008 at 10:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> David Ferguson wrote on Thu, 30 Oct 2008 at 10:47 -0400:
>>> Daniel,
>>>
>>> Thanks for confirming the problem even with the trunk build. I'll post this
>>> to dev@subversion then.
>>>
>> If I saw here, the other devs will see it too. :) But in the meantime,
>> I looked into the code (libsvn_client/merge.c) and couldn't find how the
>> other repository's UUID is even transferred to the wc layer, so another
>> eye on this would be appreciated.
>
> I can't see where this happening either. I think I've narrowed it
> down to a couple of WC functions but it's still unclear to me how it
> gets there in the first place.
I know where this happens. See attached patch which, I think, fixes the
problem.
> I've attached a patch the adds a test to the test_suite. I'd
> appreciate feedback on it Daniel. If it looks good, we can at least
> get the test in and figure out how to solve the real problem.
>
> -John
>
> ======================
> Add a test for checking the uuid of a file merged from a foreign repository.
>
> * subversion/tests/cmdline/merge_tests.py
> (foreign_repos_uuid): New.
>
> (test_list): Add foreign_repos_uuid as XFAIL.
Thanks for the test. Only problem is that in the *correct* behavior case
(where the foreign merged add becomes just an add), 'svn info' want show the
"Repository UUID" line in the output at all. This causes your test to choke.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: BUG? Merging from foreign repository corrupts UUID
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Szakmeister wrote:
> On Thu, Oct 30, 2008 at 10:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> David Ferguson wrote on Thu, 30 Oct 2008 at 10:47 -0400:
>>> Daniel,
>>>
>>> Thanks for confirming the problem even with the trunk build. I'll post this
>>> to dev@subversion then.
>>>
>> If I saw here, the other devs will see it too. :) But in the meantime,
>> I looked into the code (libsvn_client/merge.c) and couldn't find how the
>> other repository's UUID is even transferred to the wc layer, so another
>> eye on this would be appreciated.
>
> I can't see where this happening either. I think I've narrowed it
> down to a couple of WC functions but it's still unclear to me how it
> gets there in the first place.
I know where this happens. See attached patch which, I think, fixes the
problem.
> I've attached a patch the adds a test to the test_suite. I'd
> appreciate feedback on it Daniel. If it looks good, we can at least
> get the test in and figure out how to solve the real problem.
>
> -John
>
> ======================
> Add a test for checking the uuid of a file merged from a foreign repository.
>
> * subversion/tests/cmdline/merge_tests.py
> (foreign_repos_uuid): New.
>
> (test_list): Add foreign_repos_uuid as XFAIL.
Thanks for the test. Only problem is that in the *correct* behavior case
(where the foreign merged add becomes just an add), 'svn info' want show the
"Repository UUID" line in the output at all. This causes your test to choke.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: BUG? Merging from foreign repository corrupts UUID
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thu, Oct 30, 2008 at 10:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> David Ferguson wrote on Thu, 30 Oct 2008 at 10:47 -0400:
>> Daniel,
>>
>> Thanks for confirming the problem even with the trunk build. I'll post this
>> to dev@subversion then.
>>
>
> If I saw here, the other devs will see it too. :) But in the meantime,
> I looked into the code (libsvn_client/merge.c) and couldn't find how the
> other repository's UUID is even transferred to the wc layer, so another
> eye on this would be appreciated.
I can't see where this happening either. I think I've narrowed it
down to a couple of WC functions but it's still unclear to me how it
gets there in the first place.
>>
>> Btw, here is an example of a command that fails due to the bad UUID's in the
>> working copy:
>>
>
> Thanks, I can reproduce it (even without the 'mv').
I've attached a patch the adds a test to the test_suite. I'd
appreciate feedback on it Daniel. If it looks good, we can at least
get the test in and figure out how to solve the real problem.
-John
======================
Add a test for checking the uuid of a file merged from a foreign repository.
* subversion/tests/cmdline/merge_tests.py
(foreign_repos_uuid): New.
(test_list): Add foreign_repos_uuid as XFAIL.
Re: BUG? Merging from foreign repository corrupts UUID
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thu, Oct 30, 2008 at 10:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> David Ferguson wrote on Thu, 30 Oct 2008 at 10:47 -0400:
>> Daniel,
>>
>> Thanks for confirming the problem even with the trunk build. I'll post this
>> to dev@subversion then.
>>
>
> If I saw here, the other devs will see it too. :) But in the meantime,
> I looked into the code (libsvn_client/merge.c) and couldn't find how the
> other repository's UUID is even transferred to the wc layer, so another
> eye on this would be appreciated.
I can't see where this happening either. I think I've narrowed it
down to a couple of WC functions but it's still unclear to me how it
gets there in the first place.
>>
>> Btw, here is an example of a command that fails due to the bad UUID's in the
>> working copy:
>>
>
> Thanks, I can reproduce it (even without the 'mv').
I've attached a patch the adds a test to the test_suite. I'd
appreciate feedback on it Daniel. If it looks good, we can at least
get the test in and figure out how to solve the real problem.
-John
======================
Add a test for checking the uuid of a file merged from a foreign repository.
* subversion/tests/cmdline/merge_tests.py
(foreign_repos_uuid): New.
(test_list): Add foreign_repos_uuid as XFAIL.
Re: BUG? Merging from foreign repository corrupts UUID
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
David Ferguson wrote on Thu, 30 Oct 2008 at 10:47 -0400:
> Daniel,
>
> Thanks for confirming the problem even with the trunk build. I'll post this
> to dev@subversion then.
>
If I saw here, the other devs will see it too. :) But in the meantime,
I looked into the code (libsvn_client/merge.c) and couldn't find how the
other repository's UUID is even transferred to the wc layer, so another
eye on this would be appreciated.
>
> Btw, here is an example of a command that fails due to the bad UUID's in the
> working copy:
>
Thanks, I can reproduce it (even without the 'mv').
Daniel
> # Move the repository
> $ mv repo2 repo2_moved
>
> # Run switch to relocate the work2 tree to the moved repository
> $ svn sw --relocate file:///home/dferguso/breakage/repo2
> file:///home/dferguso/breakage/repo2_moved work2
> svn: The repository at 'file:///home/dferguso/breakage/repo2_moved/new_file'
> has uuid 'efa31701-9c4b-4765-be70-c33ec061bfaa', but the WC has
> 'dcc70446-cf29-4897-9959-bc1492de7982'
>
>
>
> On Thu, Oct 30, 2008 at 10:20 AM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>
> > David Ferguson wrote on Thu, 30 Oct 2008 at 10:04 -0400:
> > > # Check info. UUID on work2 and work2/new_file don't match!!
> > > $ svn info work1 work2 work2/new_file
> > >
> > >
> > > Notice that the UUID of work2/new_file is from repository #1 !! It
> > should
> > > match the UUID of its parent directory, work2.
> >
> > Confirmed (up to this point) with trunk:
> >
> > % svn info wc1 wc2 wc1/iota wc2/iota | grep UUID
> > Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
> > Repository UUID: 87ef63c1-b93b-1d48-a7a0-e56f7abf285d
> > Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
> > Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
> >
> > > This leaves the work2
> > > directory in a bad state. Things like switch and update start
> > complaining
> > > that the UUID of the WC doesn't match the repository.
> >
> > Can't reproduce this part?
> >
> > % svn ci -m merge
> > Adding iota
> > Transmitting file data .
> > Committed revision 1.
> >
> > % svn up
> > At revision 1.
> >
> > However, even after the commit, the wc is inconsistent:
> >
> > % svn info . iota | grep UUID
> > Repository UUID: 87ef63c1-b93b-1d48-a7a0-e56f7abf285d
> > Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
> >
> >
> > Daniel
> >
> > > svn: The repository at '<full url>' has uuid 'XYZ', but the WC has
> > 'ABC'
> > >
> > > The only fix is to recheckout the work directory. Can someone else
> > confirm
> > > that this is a problem? Or is this an already-known issue? (I didn't
> > see
> > > anything in the issue tracker.)
> > >
> > > Subversion client is 1.5.3, Linux x86_64, RHEL 4, update 6.
> > >
> > > thanks,
> > > David
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: BUG? Merging from foreign repository corrupts UUID
Posted by David Ferguson <fe...@gmail.com>.
Daniel,
Thanks for confirming the problem even with the trunk build. I'll post this
to dev@subversion then.
Btw, here is an example of a command that fails due to the bad UUID's in the
working copy:
# Move the repository
$ mv repo2 repo2_moved
# Run switch to relocate the work2 tree to the moved repository
$ svn sw --relocate file:///home/dferguso/breakage/repo2
file:///home/dferguso/breakage/repo2_moved work2
svn: The repository at 'file:///home/dferguso/breakage/repo2_moved/new_file'
has uuid 'efa31701-9c4b-4765-be70-c33ec061bfaa', but the WC has
'dcc70446-cf29-4897-9959-bc1492de7982'
On Thu, Oct 30, 2008 at 10:20 AM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
> David Ferguson wrote on Thu, 30 Oct 2008 at 10:04 -0400:
> > # Check info. UUID on work2 and work2/new_file don't match!!
> > $ svn info work1 work2 work2/new_file
> >
> >
> > Notice that the UUID of work2/new_file is from repository #1 !! It
> should
> > match the UUID of its parent directory, work2.
>
> Confirmed (up to this point) with trunk:
>
> % svn info wc1 wc2 wc1/iota wc2/iota | grep UUID
> Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
> Repository UUID: 87ef63c1-b93b-1d48-a7a0-e56f7abf285d
> Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
> Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
>
> > This leaves the work2
> > directory in a bad state. Things like switch and update start
> complaining
> > that the UUID of the WC doesn't match the repository.
>
> Can't reproduce this part?
>
> % svn ci -m merge
> Adding iota
> Transmitting file data .
> Committed revision 1.
>
> % svn up
> At revision 1.
>
> However, even after the commit, the wc is inconsistent:
>
> % svn info . iota | grep UUID
> Repository UUID: 87ef63c1-b93b-1d48-a7a0-e56f7abf285d
> Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
>
>
> Daniel
>
> > svn: The repository at '<full url>' has uuid 'XYZ', but the WC has
> 'ABC'
> >
> > The only fix is to recheckout the work directory. Can someone else
> confirm
> > that this is a problem? Or is this an already-known issue? (I didn't
> see
> > anything in the issue tracker.)
> >
> > Subversion client is 1.5.3, Linux x86_64, RHEL 4, update 6.
> >
> > thanks,
> > David
> >
>
Re: BUG? Merging from foreign repository corrupts UUID
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
David Ferguson wrote on Thu, 30 Oct 2008 at 10:04 -0400:
> # Check info. UUID on work2 and work2/new_file don't match!!
> $ svn info work1 work2 work2/new_file
>
>
> Notice that the UUID of work2/new_file is from repository #1 !! It should
> match the UUID of its parent directory, work2.
Confirmed (up to this point) with trunk:
% svn info wc1 wc2 wc1/iota wc2/iota | grep UUID
Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
Repository UUID: 87ef63c1-b93b-1d48-a7a0-e56f7abf285d
Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
> This leaves the work2
> directory in a bad state. Things like switch and update start complaining
> that the UUID of the WC doesn't match the repository.
Can't reproduce this part?
% svn ci -m merge
Adding iota
Transmitting file data .
Committed revision 1.
% svn up
At revision 1.
However, even after the commit, the wc is inconsistent:
% svn info . iota | grep UUID
Repository UUID: 87ef63c1-b93b-1d48-a7a0-e56f7abf285d
Repository UUID: ce3a91fd-a72c-2141-b64e-ae7bb47ba96e
Daniel
> svn: The repository at '<full url>' has uuid 'XYZ', but the WC has 'ABC'
>
> The only fix is to recheckout the work directory. Can someone else confirm
> that this is a problem? Or is this an already-known issue? (I didn't see
> anything in the issue tracker.)
>
> Subversion client is 1.5.3, Linux x86_64, RHEL 4, update 6.
>
> thanks,
> David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org