You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sebastian Celis <su...@sebastiancelis.com> on 2009/03/24 14:42:06 UTC
[BUG] Merging to a branch with sparsely checked out files fails
without error
Hello,
I ran into a bug while attempting to perform a merge inside of a working copy with lots of sparsely checked out directories. In my particular situation, svn says that the merge succeeded, but none of the file contents have been modified. Only a few svn:merge-info properties have been set.
I believe the issue only occurs when merging into a branch that has been sparsely checked out. Parent directories to the branch can be sparsely checked out without issue, but if the branch itself is sparsely checked out, this issue will occur.
I am attaching a shell script that reproduces the bug. I have confirmed that this happens in both the 1.6.0 client as well as 1.5.6.
Thank you,
Sebastian Celis
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Kari Granö <ka...@gmail.com>.
Peter Samuelson wrote:
> > Yes, if the trunk changes get silently reverted, then this is really
> dangerous.
> >
> > But could the merge be smarter here? I mean, the last change on
> > branch-1/docs is at r99 (it was never changed in branch-1 since it is
> > sparse in the working copy).
>
> Well ... Subversion knows (or could know) that branch-1/docs has not
> been updated, but it does not know _why_. You assume that this is
> because whoever worked in branch-1 used a sparse checkout. But perhaps
> whoever merged from trunk r101-123 really did merge the docs/
> directory, but then looked at it and decided the changes were
> incorrect. So he reverted the whole directory before committing the
> merge.
Right, I can see this now. So there will always be a need for subtree
mergeinfo with sparse merges. But I hope it will be lot less annoying, if
(and when :) Paul manages to reduce it only to the really affected subtrees.
Kari.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1433928
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Peter Samuelson <pe...@p12n.org>.
> > 1) You have a repos structured like this:
> >
> > trunk
> > trunk/src
> > trunk/docs
> >
> > 2) Copy trunk@99 to branches/branch-1 in r100
> >
> > 3) Checkout branches/branch-1 such that the docs subtree is missing
> > due to a shallow checkout:
> >
> > branches (depth infinity)
> > branches/src (depth infinity)
> > branches/docs (depth empty)
> >
> > 4) Make some changes under both trunk/src and trunk/docs in r101-123.
> >
> > 5) In r124-r125 we make some changes to branches/branch-1
> >
> > 6) Merge all available revisions (i.e. now -r or -c option is
> > specified) from trunk to branches/branch-1.
> >
> > Mergeinfo is set as follows:
> >
> > branches/branch-1 '/trunk:101-125'
> > branches/branch-1/docs '/trunk:101-125*'
> >
> > Before committing this merge as r126 we delete the mergeinfo set on
> > 'docs'.
> >
> > 6) Now we reintegrate branches/branch-1 back to trunk. Under the
> > covers reintegrate is doing the following 2-URL merge:
> >
> > svn merge trunk_URL@125 branch-1_URL@126 trunk_working_copy
> >
> > But wait! The merge we did in #6 never brought the changes to the
> > docs subtree that we made in #4 (because the subtree wasn't present to
> > receive them). So branch-1_URL/docs@126 is the same as
> > trunk_URL/docs@*99*. The 2-URL merge will actually revert those
> > changes to trunk/docs that we made in #4, which is almost certainly
> > not what we intended. Does that make sense?
[Kari Granö]
> Yes, if the trunk changes get silently reverted, then this is really dangerous.
>
> But could the merge be smarter here? I mean, the last change on
> branch-1/docs is at r99 (it was never changed in branch-1 since it is
> sparse in the working copy).
Well ... Subversion knows (or could know) that branch-1/docs has not
been updated, but it does not know _why_. You assume that this is
because whoever worked in branch-1 used a sparse checkout. But perhaps
whoever merged from trunk r101-123 really did merge the docs/
directory, but then looked at it and decided the changes were
incorrect. So he reverted the whole directory before committing the
merge.
The 'merge --reintegrate' is not necessarily done from the same
checkout where the branch work was done. In fact it doesn't need a
branch checkout at all, only a trunk checkout. So Subversion can't
assume anything about whether the previous trunk -> branch-1 merge was
done in a sparse checkout.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Kari Granö <ka...@gmail.com>.
On Wed, 25 Mar 2009 17:31:34 -0400 ptburba_at_gmail.com> wrote:
> > Hm, I guess I *have to* read that paper now :). Yes, I've been
> reverting
> > subtree mergeinfo produced by sparse merges for those subtrees that
> I've
> > figured are not affected by the merge. That is, if merging rX into
> my
> > sparse working copy only affects paths below /trunk/src, I've felt it
> safe
> > to revert the mergeinfo generated for the sparse /trunk/testdata
> folder. Is
> > this an unsafe practice?
>
> Assuming that there would only be changes under trunk/src *even* if
> the other shallow subtrees were present, then what you are doing
> should be safe (in fact I'm presently looking into making what you are
> doing the default behavior for merge).
Hi Paul,
That sounds cool! Making the merge produce only as little mergeinfo as needed will make it much more understandable as to why it's there.
> But when you said "sparse working copies invariably produce subtree
> mergeinfo, which makes it hard to reason about the performed merges
> and can cause problems with merge --reintegrate" I was imagining
> something like this:
>
> 1) You have a repos structured like this:
>
> trunk
> trunk/src
> trunk/docs
>
> 2) Copy trunk@99 to branches/branch-1 in r100
>
> 3) Checkout branches/branch-1 such that the docs subtree is missing
> due to a shallow checkout:
>
> branches (depth infinity)
> branches/src (depth infinity)
> branches/docs (depth empty)
>
> 4) Make some changes under both trunk/src and trunk/docs in r101-123.
>
> 5) In r124-r125 we make some changes to branches/branch-1
>
> 6) Merge all available revisions (i.e. now -r or -c option is
> specified) from trunk to branches/branch-1.
>
> Mergeinfo is set as follows:
>
> branches/branch-1 '/trunk:101-125'
> branches/branch-1/docs '/trunk:101-125*'
>
> Before committing this merge as r126 we delete the mergeinfo set on
> 'docs'.
>
> 6) Now we reintegrate branches/branch-1 back to trunk. Under the
> covers reintegrate is doing the following 2-URL merge:
>
> svn merge trunk_URL@125 branch-1_URL@126 trunk_working_copy
>
> But wait! The merge we did in #6 never brought the changes to the
> docs subtree that we made in #4 (because the subtree wasn't present to
> receive them). So branch-1_URL/docs@126 is the same as
> trunk_URL/docs@*99*. The 2-URL merge will actually revert those
> changes to trunk/docs that we made in #4, which is almost certainly
> not what we intended. Does that make sense?
Yes, if the trunk changes get silently reverted, then this is really dangerous.
But could the merge be smarter here? I mean, the last change on branch-1/docs is at r99 (it was never changed in branch-1 since it is sparse in the working copy). This should be the case even when merging from branch-1@126. Couldn't the merge therefore notice that branch-1/docs@126 is really branch-1/docs@99 which is *older* than trunk/docs@123 and skip the harmful merge?
Is this distinction technically impossible to make, or am I missing something obvious?
Kari.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1421079
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Mar 25, 2009 at 4:56 PM, Kari Granö <ka...@gmail.com> wrote:
> On Wed, 25 Mar 2009 09:48:18 -0400, Paul Burba <ptburba_at_gmail.com> wrote:
>>> On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato
> <cmpilato_at_collab.net> wrote:
>>>> 2b. Â Subversion can record the merge on every present sibling of
> /trunk/testdata -- /trunk/src and /trunk/doc, in this case.
>>>
>>> As others have pointed out, this happens currently when you specify
> "--depth=infinity".
>>> Â Just having this as the default behavior would already be much better.
>
> Hi Paul,
>
>> Everyone on this thread seems to agree that is a better option. I'll
>> look into it a bit more to make sure there isn't some problem lurking
>> in the details and then propose this change in a separate thread.
>
> Thanks, much appreciated!
>
>>> However, this leads to another, unrelated problem: merges into sparse
>>> working copies invariably produce subtree mergeinfo,
>> Yes, this is intentional, we need some way to record that the merge
>> was never performed for the "missing" portions of the working copy,
>> i.e. the shallow subtrees. This is explained in painful detail in
>> http://www.collab.net/community/subversion/articles/merge-info.html in
>> the "Mergeinfo Inheritance and Non-Inheritable Ranges" section.
>
> Thanks for the pointer, this will be great stuff to read during my winter
> vacation next week :)
Oh no, don't ruin your vacation!
>>> which makes it hard to reason about the performed merges and can cause
> problems
>>> with "merge --reintegrate".
>> Problems? I can't see how it would *ever* work. Reintegrate was
>> never intended to support the use case where you had a shallow branch
>> working copy. Keep in mind that --reintegrate is simply a shortcut
>> for a 2-URL merge along with some safety checks
>
> Ok, good to hear this spelled out. In our scenario sparse (or switched)
> working copies are typical, as the repository contains huge subtrees that do
> not interest everyone.
>
>>> I find myself manually fixing svn:mergeinfo after such merges, which is
>>> a bit tedious.
>> By fix you mean delete? If so and it works for you great, but there
>> are very simple use cases where doing this will revert changes on your
>> trunk when reintegrating (hence the safety checks I mentioned before).
>
> Hm, I guess I *have to* read that paper now :). Yes, I've been reverting
> subtree mergeinfo produced by sparse merges for those subtrees that I've
> figured are not affected by the merge. That is, if merging rX into my
> sparse working copy only affects paths below /trunk/src, I've felt it safe
> to revert the mergeinfo generated for the sparse /trunk/testdata folder. Is
> this an unsafe practice?
Assuming that there would only be changes under trunk/src *even* if
the other shallow subtrees were present, then what you are doing
should be safe (in fact I'm presently looking into making what you are
doing the default behavior for merge).
But when you said "sparse working copies invariably produce subtree
mergeinfo, which makes it hard to reason about the performed merges
and can cause problems with merge --reintegrate" I was imagining
something like this:
1) You have a repos structured like this:
trunk
trunk/src
trunk/docs
2) Copy trunk@99 to branches/branch-1 in r100
3) Checkout branches/branch-1 such that the docs subtree is missing
due to a shallow checkout:
branches (depth infinity)
branches/src (depth infinity)
branches/docs (depth empty)
4) Make some changes under both trunk/src and trunk/docs in r101-123.
5) In r124-r125 we make some changes to branches/branch-1
6) Merge all available revisions (i.e. now -r or -c option is
specified) from trunk to branches/branch-1.
Mergeinfo is set as follows:
branches/branch-1 '/trunk:101-125'
branches/branch-1/docs '/trunk:101-125*'
Before committing this merge as r126 we delete the mergeinfo set on 'docs'.
6) Now we reintegrate branches/branch-1 back to trunk. Under the
covers reintegrate is doing the following 2-URL merge:
svn merge trunk_URL@125 branch-1_URL@126 trunk_working_copy
But wait! The merge we did in #6 never brought the changes to the
docs subtree that we made in #4 (because the subtree wasn't present to
receive them). So branch-1_URL/docs@126 is the same as
trunk_URL/docs@*99*. The 2-URL merge will actually revert those
changes to trunk/docs that we made in #4, which is almost certainly
not what we intended. Does that make sense?
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1420387
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Kari Granö <ka...@gmail.com>.
On Wed, 25 Mar 2009 09:48:18 -0400, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato
<cmpilato_at_collab.net> wrote:
>>> 2b. Â Subversion can record the merge on every present sibling of
/trunk/testdata -- /trunk/src and /trunk/doc, in this case.
>>
>> As others have pointed out, this happens currently when you specify
"--depth=infinity".
>> Â Just having this as the default behavior would already be much better.
Hi Paul,
> Everyone on this thread seems to agree that is a better option. I'll
> look into it a bit more to make sure there isn't some problem lurking
> in the details and then propose this change in a separate thread.
Thanks, much appreciated!
>> However, this leads to another, unrelated problem: merges into sparse
>> working copies invariably produce subtree mergeinfo,
> Yes, this is intentional, we need some way to record that the merge
> was never performed for the "missing" portions of the working copy,
> i.e. the shallow subtrees. This is explained in painful detail in
> http://www.collab.net/community/subversion/articles/merge-info.html in
> the "Mergeinfo Inheritance and Non-Inheritable Ranges" section.
Thanks for the pointer, this will be great stuff to read during my winter
vacation next week :)
>> which makes it hard to reason about the performed merges and can cause
problems
>> with "merge --reintegrate".
> Problems? I can't see how it would *ever* work. Reintegrate was
> never intended to support the use case where you had a shallow branch
> working copy. Keep in mind that --reintegrate is simply a shortcut
> for a 2-URL merge along with some safety checks
Ok, good to hear this spelled out. In our scenario sparse (or switched)
working copies are typical, as the repository contains huge subtrees that do
not interest everyone.
>> I find myself manually fixing svn:mergeinfo after such merges, which is
>> a bit tedious.
> By fix you mean delete? If so and it works for you great, but there
> are very simple use cases where doing this will revert changes on your
> trunk when reintegrating (hence the safety checks I mentioned before).
Hm, I guess I *have to* read that paper now :). Yes, I've been reverting
subtree mergeinfo produced by sparse merges for those subtrees that I've
figured are not affected by the merge. That is, if merging rX into my
sparse working copy only affects paths below /trunk/src, I've felt it safe
to revert the mergeinfo generated for the sparse /trunk/testdata folder. Is
this an unsafe practice?
Kari
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1420011
RE: Re: [BUG] Merging to a branch with sparsely checked out files
fails without error
Posted by Sebastian Celis <su...@sebastiancelis.com>.
> I recall that too, but can't find it. Anyhow, the way it works is:
>
> "The default depth of a merge is the same as the merge target."
>
> For example, if you don't specify a --depth and merge into directory
> that was checked out at depth=immediates, then the merge will proceed
> as if you specified --depth immediates. It won't matter if some of
> the target's children are themselves checked out a a greater depth.
Interesting. However, I do not know if this is obvious to the user. At least it wasn't to me or to any of my coworkers. Can we open a discussion about how this currently works and whether it should be changed or better documented? I see a few potential solutions for preventing future confusion:
1) Change svn merge so that if --depth is not specified, it defaults to "infinity".
This is what I expected svn to do. As a user, when I merge a particular revision (or range of revisions) into my current working copy, I expect the changes made in those revisions to be fully merged. If they are not, I expect to be told so.
This change would have an interesting side-effect. If a user attempts to a merge a revision which changed a file that is not in the user's working copy, that file (or a parent directory to that file) will be marked as conflicted. This might not be a bad thing, and immediately tells the user what went wrong. They can then revert that conflict and commit if that is what they want to do. Or they can check out the files they are missing and redo the merge.
2) Better document the current functionality.
This could done with additional information in 'svn help merge'. Maybe another paragraph at the top? Or maybe a few additional sentences when discussing the depth parameter, specifically stating the default value.
3) Clarify the functionality in the output of 'svn merge'.
a) When performing any merge, a sentence could be printed that describes the operation about to be performed (something like: Performing merge on . with depth=files).
b) When performing a merge, if parts of the revision(s) could not be merged due to a sparsely checked out working copy, 'svn merge' could print a helpful message to the user (something like: The following files could not be updated as they are not checked out in the working copy: ...).
I think I am leaning toward (1) or (3).
- Sebastian Celis
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405550
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Mar 24, 2009 at 11:05 AM, Mark Phippard <ma...@gmail.com> wrote:
> Just add --depth=infinity to your merge command and it works fine.
> This is the expected behavior. I am not exactly sure why, but it has
> been explained before on this list.
I recall that too, but can't find it. Anyhow, the way it works is:
"The default depth of a merge is the same as the merge target."
For example, if you don't specify a --depth and merge into directory
that was checked out at depth=immediates, then the merge will proceed
as if you specified --depth immediates. It won't matter if some of
the target's children are themselves checked out a a greater depth.
Paul
> Mark
>
> On Tue, Mar 24, 2009 at 10:42 AM, Sebastian Celis
> <su...@sebastiancelis.com> wrote:
>> Hello,
>>
>> I ran into a bug while attempting to perform a merge inside of a working copy with lots of sparsely checked out directories. In my particular situation, svn says that the merge succeeded, but none of the file contents have been modified. Only a few svn:merge-info properties have been set.
>>
>> I believe the issue only occurs when merging into a branch that has been sparsely checked out. Parent directories to the branch can be sparsely checked out without issue, but if the branch itself is sparsely checked out, this issue will occur.
>>
>> I am attaching a shell script that reproduces the bug. I have confirmed that this happens in both the 1.6.0 client as well as 1.5.6.
>>
>> Thank you,
>> Sebastian Celis
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1403046
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1403978
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Mark Phippard <ma...@gmail.com>.
Just add --depth=infinity to your merge command and it works fine.
This is the expected behavior. I am not exactly sure why, but it has
been explained before on this list.
Mark
On Tue, Mar 24, 2009 at 10:42 AM, Sebastian Celis
<su...@sebastiancelis.com> wrote:
> Hello,
>
> I ran into a bug while attempting to perform a merge inside of a working copy with lots of sparsely checked out directories. In my particular situation, svn says that the merge succeeded, but none of the file contents have been modified. Only a few svn:merge-info properties have been set.
>
> I believe the issue only occurs when merging into a branch that has been sparsely checked out. Parent directories to the branch can be sparsely checked out without issue, but if the branch itself is sparsely checked out, this issue will occur.
>
> I am attaching a shell script that reproduces the bug. I have confirmed that this happens in both the 1.6.0 client as well as 1.5.6.
>
> Thank you,
> Sebastian Celis
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1403046
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Kari Granö wrote:
>> On Tue, 24 Mar 2009 13:07:01 -0400 Paul Burba <ptburba_at_gmail.com> wrote:
>>>> Just add --depth=infinity to your merge command and it works fine.
>>>> This is the expected behavior. Â I am not exactly sure why, but it has
>>>> been explained before on this list.
>>
>>> I recall that too, but can't find it. Anyhow, the way it works is:
>>> "The default depth of a merge is the same as the merge target."
>>> For example, if you don't specify a --depth and merge into directory
>>> that was checked out at depth=immediates, then the merge will proceed
>>> as if you specified --depth immediates. It won't matter if some of
>>> the target's children are themselves checked out a a greater depth.
>>
>> This default is a bit surprising, if you ask me. If I have a sparse working
>> copy, why would I want to limit merge depth to the sparse root of the merge
>> target? I can't come up with any use case.
>
> I think there are technical challenges here that might have come into play,
> namely around merge tracking.
>
> Say in my repository's trunk, I have the following directories: "src",
> "doc", "testdata". Now let's say I've sparsely checked out my trunk without
> the "testdata" directory:
>
> /trunk
> /trunk/src
> /trunk/doc
>
> One day, I need to merge some changes from a branch (/branches/feature), so
> I issue some inspired merge command. What if, in the set of revisions I
> wish to merge, there are changes inside of /branches/feature/testdata?
> There are some options:
>
> 1. Subversion can fail the merge immediately with a big "Sorry, I can't
> deal with that" error. This might be feasible today -- I'm not sure.
>
> 2. Subversion can attempt the merge anyway, printing "Skipped" messages for
> all the paths it wanted to modify as part of the merge, but couldn't. (Does
> this cause tree conflicts in 1.6-era code? I'm not sure.)
>
> 2a. Subversion can record in /trunk the merge of /branches/feature. But
> that's not really true, because it didn't merge all the changes. And
> because of the storage model for mergeinfo, the only place to record the
> fact that /trunk/testdata didn't get the merged changes is on
> /trunk/testdata, which isn't available for said recording by virtue of not
> being present in the working copy.
>
> 2b. Subversion can record the merge on every present sibling of
> /trunk/testdata -- /trunk/src and /trunk/doc, in this case.
Mike,
Actually this is what happens today. It uses non-inheritable
mergeinfo on the target and (if you specify --depth infinity) it sets
normal inheritable mergeinfo on the children that are present.
To the larger question of the default, I think I agree with the
earlier posters, the default should be infinity. I was doing some
quick testing of your example and forgot the --depth option on the
merge and found myself thinking "what the $#&!"
Paul
> 2c. Subversion can avoid recording the merge at all.
>
> The natural follow questions involve dealing with even-less-trivial cases
> where the merge target is a hodge-podge of depths.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405815
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405936
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Kari Granö wrote:
>> On Tue, 24 Mar 2009 13:07:01 -0400 Paul Burba <ptburba_at_gmail.com> wrote:
>>>> Just add --depth=infinity to your merge command and it works fine.
>>>> This is the expected behavior. Â I am not exactly sure why, but it has
>>>> been explained before on this list.
>>
>>> I recall that too, but can't find it. Anyhow, the way it works is:
>>> "The default depth of a merge is the same as the merge target."
>>> For example, if you don't specify a --depth and merge into directory
>>> that was checked out at depth=immediates, then the merge will proceed
>>> as if you specified --depth immediates. It won't matter if some of
>>> the target's children are themselves checked out a a greater depth.
>>
>> This default is a bit surprising, if you ask me. If I have a sparse working
>> copy, why would I want to limit merge depth to the sparse root of the merge
>> target? I can't come up with any use case.
>
> I think there are technical challenges here that might have come into play,
> namely around merge tracking.
This is just a guess, but I think someone had the same concerns when
the current behavior was added. However, see below ....
> Say in my repository's trunk, I have the following directories: "src",
> "doc", "testdata". Now let's say I've sparsely checked out my trunk without
> the "testdata" directory:
>
> /trunk
> /trunk/src
> /trunk/doc
>
> One day, I need to merge some changes from a branch (/branches/feature), so
> I issue some inspired merge command. What if, in the set of revisions I
> wish to merge, there are changes inside of /branches/feature/testdata?
> There are some options:
>
> 1. Subversion can fail the merge immediately with a big "Sorry, I can't
> deal with that" error. This might be feasible today -- I'm not sure.
>
> 2. Subversion can attempt the merge anyway, printing "Skipped" messages for
> all the paths it wanted to modify as part of the merge, but couldn't. (Does
> this cause tree conflicts in 1.6-era code? I'm not sure.)
>
> 2a. Subversion can record in /trunk the merge of /branches/feature. But
> that's not really true, because it didn't merge all the changes. And
> because of the storage model for mergeinfo, the only place to record the
> fact that /trunk/testdata didn't get the merged changes is on
> /trunk/testdata, which isn't available for said recording by virtue of not
> being present in the working copy.
>
> 2b. Subversion can record the merge on every present sibling of
> /trunk/testdata -- /trunk/src and /trunk/doc, in this case.
>
> 2c. Subversion can avoid recording the merge at all.
This all had to be dealt with prior to 1.5 final release. 2b is the
option that was used, along with the non-inheritable mergeinfo syntax.
I believe there is a section on this in Paul Burba's mergeinfo
manifesto:
http://www.collab.net/community/subversion/articles/merge-info.html
I personally think it ought to behave like --depth=infinity by default.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405902
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Mar 24, 2009 at 6:03 PM, Kari Granö <ka...@gmail.com> wrote:
> On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> 2b. Subversion can record the merge on every present sibling of /trunk/testdata -- /trunk/src and /trunk/doc, in this case.
>
> As others have pointed out, this happens currently when you specify "--depth=infinity". Just having this as the default behavior would already be much better.
Hi Kari,
Everyone on this thread seems to agree that is a better option. I'll
look into it a bit more to make sure there isn't some problem lurking
in the details and then propose this change in a separate thread.
> However, this leads to another, unrelated problem: merges into sparse
> working copies invariably produce subtree mergeinfo,
Yes, this is intentional, we need some way to record that the merge
was never performed for the "missing" portions of the working copy,
i.e. the shallow subtrees. This is explained in painful detail in
http://www.collab.net/community/subversion/articles/merge-info.html in
the "Mergeinfo Inheritance and Non-Inheritable Ranges" section.
> which makes it hard to reason about the performed merges and can cause problems
> with "merge --reintegrate".
Problems? I can't see how it would *ever* work. Reintegrate was
never intended to support the use case where you had a shallow branch
working copy. Keep in mind that --reintegrate is simply a shortcut
for a 2-URL merge along with some safety checks to keep you from
shooting yourself in the foot. If reintegrate balks you can always
perform the underlying 2-URL merge,
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html.
> I find myself manually fixing svn:mergeinfo after such merges, which is
> a bit tedious.
By fix you mean delete? If so and it works for you great, but there
are very simple use cases where doing this will revert changes on your
trunk when reintegrating (hence the safety checks I mentioned before).
> I guess there's no way around that.
Barring fundamental changes in how mergeinfo is recorded probably not.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1415598
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Kari Granö <ka...@gmail.com>.
On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> On Tue, 24 Mar 2009 13:07:01 -0400 Paul Burba <ptburba_at_gmail.com> wrote:
>>>> Just add --depth=infinity to your merge command and it works fine.
>>>> This is the expected behavior. Â I am not exactly sure why, but it
>>>> has been explained before on this list.
>>
>>> I recall that too, but can't find it. Anyhow, the way it works is:
>>> "The default depth of a merge is the same as the merge target."
>>> For example, if you don't specify a --depth and merge into directory
>>> that was checked out at depth=immediates, then the merge will proceed
>>> as if you specified --depth immediates. It won't matter if some of
>>> the target's children are themselves checked out a a greater depth.
>>
> This default is a bit surprising, if you ask me. If I have a sparse
>> working copy, why would I want to limit merge depth to the sparse root
>> of the merge target? I can't come up with any use case.
> I think there are technical challenges here that might have come into play, namely around merge tracking.
> Say in my repository's trunk, I have the following directories: "src", "doc", "testdata". Now let's say I've sparsely checked out my trunk > without the "testdata" directory:
>
> /trunk
> /trunk/src
> /trunk/doc
>
> One day, I need to merge some changes from a branch (/branches/feature), so I issue some inspired merge command.
> What if, in the set of revisions I wish to merge, there are changes inside of /branches/feature/testdata?
> There are some options:
>
> 1. Subversion can fail the merge immediately with a big "Sorry, I can't deal with that" error. This might be feasible today -- I'm not sure.
>
> 2. Subversion can attempt the merge anyway, printing "Skipped" messages for all the paths it wanted to modify as part of the merge,
> but couldn't. (Does this cause tree conflicts in 1.6-era code? I'm not sure.)
>
> 2a. Subversion can record in /trunk the merge of /branches/feature. But that's not really true, because it didn't merge all the changes.
> And because of the storage model for mergeinfo, the only place to record the fact that /trunk/testdata didn't get the merged changes is
> on /trunk/testdata, which isn't available for said recording by virtue of not being present in the working copy.
>
> 2b. Subversion can record the merge on every present sibling of /trunk/testdata -- /trunk/src and /trunk/doc, in this case.
As others have pointed out, this happens currently when you specify "--depth=infinity". Just having this as the default behavior would already be much better.
However, this leads to another, unrelated problem: merges into sparse working copies invariably produce subtree mergeinfo, which makes it hard to reason about the performed merges and can cause problems with "merge --reintegrate". I find myself manually fixing svn:mergeinfo after such merges, which is a bit tedious. I guess there's no way around that.
Kari.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1406495
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by "C. Michael Pilato" <cm...@collab.net>.
Kari Granö wrote:
> On Tue, 24 Mar 2009 13:07:01 -0400 Paul Burba <ptburba_at_gmail.com> wrote:
>>> Just add --depth=infinity to your merge command and it works fine.
>>> This is the expected behavior. Â I am not exactly sure why, but it has
>>> been explained before on this list.
>
>> I recall that too, but can't find it. Anyhow, the way it works is:
>> "The default depth of a merge is the same as the merge target."
>> For example, if you don't specify a --depth and merge into directory
>> that was checked out at depth=immediates, then the merge will proceed
>> as if you specified --depth immediates. It won't matter if some of
>> the target's children are themselves checked out a a greater depth.
>
> This default is a bit surprising, if you ask me. If I have a sparse working
> copy, why would I want to limit merge depth to the sparse root of the merge
> target? I can't come up with any use case.
I think there are technical challenges here that might have come into play,
namely around merge tracking.
Say in my repository's trunk, I have the following directories: "src",
"doc", "testdata". Now let's say I've sparsely checked out my trunk without
the "testdata" directory:
/trunk
/trunk/src
/trunk/doc
One day, I need to merge some changes from a branch (/branches/feature), so
I issue some inspired merge command. What if, in the set of revisions I
wish to merge, there are changes inside of /branches/feature/testdata?
There are some options:
1. Subversion can fail the merge immediately with a big "Sorry, I can't
deal with that" error. This might be feasible today -- I'm not sure.
2. Subversion can attempt the merge anyway, printing "Skipped" messages for
all the paths it wanted to modify as part of the merge, but couldn't. (Does
this cause tree conflicts in 1.6-era code? I'm not sure.)
2a. Subversion can record in /trunk the merge of /branches/feature. But
that's not really true, because it didn't merge all the changes. And
because of the storage model for mergeinfo, the only place to record the
fact that /trunk/testdata didn't get the merged changes is on
/trunk/testdata, which isn't available for said recording by virtue of not
being present in the working copy.
2b. Subversion can record the merge on every present sibling of
/trunk/testdata -- /trunk/src and /trunk/doc, in this case.
2c. Subversion can avoid recording the merge at all.
The natural follow questions involve dealing with even-less-trivial cases
where the merge target is a hodge-podge of depths.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405815
Re: [BUG] Merging to a branch with sparsely checked out files fails
without error
Posted by Kari Granö <ka...@gmail.com>.
On Tue, 24 Mar 2009 13:07:01 -0400 Paul Burba <ptburba_at_gmail.com> wrote:
>> Just add --depth=infinity to your merge command and it works fine.
>> This is the expected behavior. Â I am not exactly sure why, but it has
>> been explained before on this list.
> I recall that too, but can't find it. Anyhow, the way it works is:
> "The default depth of a merge is the same as the merge target."
> For example, if you don't specify a --depth and merge into directory
> that was checked out at depth=immediates, then the merge will proceed
> as if you specified --depth immediates. It won't matter if some of
> the target's children are themselves checked out a a greater depth.
This default is a bit surprising, if you ask me. If I have a sparse working
copy, why would I want to limit merge depth to the sparse root of the merge
target? I can't come up with any use case.
For TortoiseSVN (and possibly other GUI clients) this is even misleading,
since TSVN shows default depth as "Working copy" in the GUI. When you merge
into a sparse working copy, you have to change the "working copy" depth to
"fully recursive" in order to get a meaningful merge. Not a Subversion
issue, but proves to show that this behavior surprises many people.
Is there any possibility for changing this default?
Regards,
Kari
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405579