Re: Question

[Rob Pointer]

And yes I know it does matter what way you invoke the tool, I was trying to
figure out what was going on with the original problem by putting together
a quick scenario (OK a slightly wobbly one).
But I had to jump to conclusions to guess what was occurring
in the original question. How else can you get someone to say 'no we didn't
do it that way, we did it this way' :) :)

However your reply tells me that you also jumped to a conclusion of your
own about what I was saying ;)

On 9 December 2011 16:54, Rob Pointer  wrote:

> Oh and Stefan
>
> "Again, please verify that you're invoking the tool in the right way
> before jumping to conclusions."
>
> Jumping to conclusions is the only way I get exercise :) :)
>
> On 9 December 2011 16:52, Rob Pointer  wrote:
>
>> Stefan
>> That's exactly what I was saying, that if any merging/copy has occurred
>> from trunk to branch, then you need to use the reintegrate merge.  if you
>> don't then that's when you get merge conflicts.
>>
>>
>> On 9 December 2011 14:00, Stefan Sperling  wrote:
>>
>>> On Fri, Dec 09, 2011 at 01:05:02PM +, Rob Pointer wrote:
>>> > Mark
>>> > If you put changes multiple times from trunk to a branch (in
>>> development
>>> > terms, a re-base) you can cause reflective merges and actually cause
>>> more
>>> > problems.  The recommended merge back into trunk is a reintegrate
>>> merge.
>>> > I am not sure if this has been addressed in 1.7, but  certainly for
>>> earlier
>>> > versions (anyone please correct me if I am wrong here though :) ).
>>> >
>>> > The scenario goes
>>> > 1) trunk contains file A
>>> > 2) copy trunk to branch1
>>> > 3) modify file A in branch1
>>> > 4) add folderb/fileb in trunk
>>> > 5) branch (copy) folderb into branch (or merge if it actually works :)
>>> )
>>> > 6) do some changes to file A and ffileb
>>> > 7) merge back into trunk.
>>> >
>>> > SVN seems to get confused and when it checks the history of both trunk
>>> and
>>> > branch1 it doesn't know that the folderb/fileb was added in branch1
>>> using a
>>> > copy, therefore it just thinks you added the files on trunk and then
>>> > branch1 as two separate operations (for any clearcase users this is an
>>> evil
>>> > twin scenario).  Therefore SVN will create a tree conflict when merging
>>> > your branch back into trunk.
>>>
>>> Wrong, wrong, wrong. You may believe that Subversion is broken but in
>>> fact you're just pushing its buttons the wrong way.
>>>
>>> To be clear, if you use the correct merge syntax for each step your
>>> scenario works just fine. And this applies to 1.6 as well as 1.7.
>>>
>>> To demonstrate:
>>>
>>> + rm -rf reflective-merge
>>> + mkdir -p reflective-merge
>>> + mkdir -p reflective-merge/trunk
>>> + echo A
>>> + > reflective-merge/trunk/A
>>> + svnadmin create /tmp/reflective-merge/repos
>>> + svn import reflective-merge/trunk
>>> file:tmp/reflective-merge/repos/trunk -m importing project tree
>>> Adding reflective-merge/trunk/A
>>>
>>> Committed revision 1.
>>> + svn copy file:tmp/reflective-merge/repos/trunk
>>> file:tmp/reflective-merge/repos/branch1 -m creating branch
>>>
>>> Committed revision 2.
>>> + rm -rf reflective-merge/trunk
>>> + svn checkout file:tmp/reflective-merge/repos/trunk
>>> reflective-merge/trunk
>>> Areflective-merge/trunk/A
>>> Checked out revision 2.
>>> + svn checkout file:tmp/reflective-merge/repos/branch1
>>> reflective-merge/branch1
>>> Areflective-merge/branch1/A
>>> Checked out revision 2.
>>> + echo foo
>>> + >> reflective-merge/branch1/A
>>> + svn commit -m modify A on branch reflective-merge/branch1
>>> Sendingreflective-merge/branch1/A
>>> Transmitting file data .
>>> Committed revision 3.
>>> + svn mkdir reflective-merge/trunk/folderb
>>> A reflective-merge/trunk/folderb
>>> + echo bar
>>> + >> reflective-merge/trunk/folderb/fileb
>>> + svn commit -m add folderb/fileb on trunk reflective-merge/trunk
>>> Adding reflective-merge/trunk/folderb
>>>
>>> Committed revision 4.
>>> + svn update reflective-merge/branch1
>>> Updating 'reflective-merge/branch1':
>>> At revision 4.
>>> + svn merge file:tmp/reflective-merge/repos/trunk
>>> reflective-merge/branch1 --accept postpone
>>> --- Merging r2 through r4 into 'reflective-merge/branch1':
>>> Areflective-merge/branch1/folderb
>>> --- Recording mergeinfo for merge of r2 through r4 into
>>> 'reflective-merge/branch1':
>>>  U   reflective-merge/branch1
>>> + svn commit reflective-merge/branch1 -m merge trunk into branch (no
>>> conflicts)
>>> Sendingreflective-merge/branch1
>>> Adding reflective-merge/branch1/folderb
>>>
>>> Committed revision 5.
>>> + echo baz
>>> + >> reflective-merge/branch1/folderb/fileb
>>> + svn commit -m modify folderb/fileb on branch reflective-merge/branch1
>>> + svn update reflective-merge/trunk
>>> Updating 'reflective-merge/trunk':
>>> At revision 5.
>>> + svn merge --reintegrate file:tmp/reflective-merge/repos/branch1
>>> reflective-merge/trunk --a

Re: Question

[Rob Pointer]

Oh and Stefan

"Again, please verify that you're invoking the tool in the right way
before jumping to conclusions."

Jumping to conclusions is the only way I get exercise :) :)

On 9 December 2011 16:52, Rob Pointer  wrote:

> Stefan
> That's exactly what I was saying, that if any merging/copy has occurred
> from trunk to branch, then you need to use the reintegrate merge.  if you
> don't then that's when you get merge conflicts.
>
>
> On 9 December 2011 14:00, Stefan Sperling  wrote:
>
>> On Fri, Dec 09, 2011 at 01:05:02PM +, Rob Pointer wrote:
>> > Mark
>> > If you put changes multiple times from trunk to a branch (in development
>> > terms, a re-base) you can cause reflective merges and actually cause
>> more
>> > problems.  The recommended merge back into trunk is a reintegrate merge.
>> > I am not sure if this has been addressed in 1.7, but  certainly for
>> earlier
>> > versions (anyone please correct me if I am wrong here though :) ).
>> >
>> > The scenario goes
>> > 1) trunk contains file A
>> > 2) copy trunk to branch1
>> > 3) modify file A in branch1
>> > 4) add folderb/fileb in trunk
>> > 5) branch (copy) folderb into branch (or merge if it actually works :) )
>> > 6) do some changes to file A and ffileb
>> > 7) merge back into trunk.
>> >
>> > SVN seems to get confused and when it checks the history of both trunk
>> and
>> > branch1 it doesn't know that the folderb/fileb was added in branch1
>> using a
>> > copy, therefore it just thinks you added the files on trunk and then
>> > branch1 as two separate operations (for any clearcase users this is an
>> evil
>> > twin scenario).  Therefore SVN will create a tree conflict when merging
>> > your branch back into trunk.
>>
>> Wrong, wrong, wrong. You may believe that Subversion is broken but in
>> fact you're just pushing its buttons the wrong way.
>>
>> To be clear, if you use the correct merge syntax for each step your
>> scenario works just fine. And this applies to 1.6 as well as 1.7.
>>
>> To demonstrate:
>>
>> + rm -rf reflective-merge
>> + mkdir -p reflective-merge
>> + mkdir -p reflective-merge/trunk
>> + echo A
>> + > reflective-merge/trunk/A
>> + svnadmin create /tmp/reflective-merge/repos
>> + svn import reflective-merge/trunk
>> file:tmp/reflective-merge/repos/trunk -m importing project tree
>> Adding reflective-merge/trunk/A
>>
>> Committed revision 1.
>> + svn copy file:tmp/reflective-merge/repos/trunk
>> file:tmp/reflective-merge/repos/branch1 -m creating branch
>>
>> Committed revision 2.
>> + rm -rf reflective-merge/trunk
>> + svn checkout file:tmp/reflective-merge/repos/trunk
>> reflective-merge/trunk
>> Areflective-merge/trunk/A
>> Checked out revision 2.
>> + svn checkout file:tmp/reflective-merge/repos/branch1
>> reflective-merge/branch1
>> Areflective-merge/branch1/A
>> Checked out revision 2.
>> + echo foo
>> + >> reflective-merge/branch1/A
>> + svn commit -m modify A on branch reflective-merge/branch1
>> Sendingreflective-merge/branch1/A
>> Transmitting file data .
>> Committed revision 3.
>> + svn mkdir reflective-merge/trunk/folderb
>> A reflective-merge/trunk/folderb
>> + echo bar
>> + >> reflective-merge/trunk/folderb/fileb
>> + svn commit -m add folderb/fileb on trunk reflective-merge/trunk
>> Adding reflective-merge/trunk/folderb
>>
>> Committed revision 4.
>> + svn update reflective-merge/branch1
>> Updating 'reflective-merge/branch1':
>> At revision 4.
>> + svn merge file:tmp/reflective-merge/repos/trunk
>> reflective-merge/branch1 --accept postpone
>> --- Merging r2 through r4 into 'reflective-merge/branch1':
>> Areflective-merge/branch1/folderb
>> --- Recording mergeinfo for merge of r2 through r4 into
>> 'reflective-merge/branch1':
>>  U   reflective-merge/branch1
>> + svn commit reflective-merge/branch1 -m merge trunk into branch (no
>> conflicts)
>> Sendingreflective-merge/branch1
>> Adding reflective-merge/branch1/folderb
>>
>> Committed revision 5.
>> + echo baz
>> + >> reflective-merge/branch1/folderb/fileb
>> + svn commit -m modify folderb/fileb on branch reflective-merge/branch1
>> + svn update reflective-merge/trunk
>> Updating 'reflective-merge/trunk':
>> At revision 5.
>> + svn merge --reintegrate file:tmp/reflective-merge/repos/branch1
>> reflective-merge/trunk --accept postpone
>> --- Merging differences between repository URLs into
>> 'reflective-merge/trunk':
>> Ureflective-merge/trunk/A
>> --- Recording mergeinfo for merge between repository URLs into
>> 'reflective-merge/trunk':
>>  U   reflective-merge/trunk
>> + svn commit reflective-merge/trunk -m reintegrate branch into trunk (no
>> conflicts)
>> Sendingreflective-merge/trunk
>> Sendingreflective-merge/trunk/A
>> Transmitting file data .
>> Committed revision 6.
>>
>> You only get a tree-conflict if you forget to use --reintegrate in the
>> last
>> merge:
>>
>> + svn update reflective-merge/trunk
>> Updating 'reflective-merge/trunk':

Re: Question

[Rob Pointer]

Stefan
That's exactly what I was saying, that if any merging/copy has occurred
from trunk to branch, then you need to use the reintegrate merge.  if you
don't then that's when you get merge conflicts.

On 9 December 2011 14:00, Stefan Sperling  wrote:

> On Fri, Dec 09, 2011 at 01:05:02PM +, Rob Pointer wrote:
> > Mark
> > If you put changes multiple times from trunk to a branch (in development
> > terms, a re-base) you can cause reflective merges and actually cause more
> > problems.  The recommended merge back into trunk is a reintegrate merge.
> > I am not sure if this has been addressed in 1.7, but  certainly for
> earlier
> > versions (anyone please correct me if I am wrong here though :) ).
> >
> > The scenario goes
> > 1) trunk contains file A
> > 2) copy trunk to branch1
> > 3) modify file A in branch1
> > 4) add folderb/fileb in trunk
> > 5) branch (copy) folderb into branch (or merge if it actually works :) )
> > 6) do some changes to file A and ffileb
> > 7) merge back into trunk.
> >
> > SVN seems to get confused and when it checks the history of both trunk
> and
> > branch1 it doesn't know that the folderb/fileb was added in branch1
> using a
> > copy, therefore it just thinks you added the files on trunk and then
> > branch1 as two separate operations (for any clearcase users this is an
> evil
> > twin scenario).  Therefore SVN will create a tree conflict when merging
> > your branch back into trunk.
>
> Wrong, wrong, wrong. You may believe that Subversion is broken but in
> fact you're just pushing its buttons the wrong way.
>
> To be clear, if you use the correct merge syntax for each step your
> scenario works just fine. And this applies to 1.6 as well as 1.7.
>
> To demonstrate:
>
> + rm -rf reflective-merge
> + mkdir -p reflective-merge
> + mkdir -p reflective-merge/trunk
> + echo A
> + > reflective-merge/trunk/A
> + svnadmin create /tmp/reflective-merge/repos
> + svn import reflective-merge/trunk
> file:tmp/reflective-merge/repos/trunk -m importing project tree
> Adding reflective-merge/trunk/A
>
> Committed revision 1.
> + svn copy file:tmp/reflective-merge/repos/trunk
> file:tmp/reflective-merge/repos/branch1 -m creating branch
>
> Committed revision 2.
> + rm -rf reflective-merge/trunk
> + svn checkout file:tmp/reflective-merge/repos/trunk
> reflective-merge/trunk
> Areflective-merge/trunk/A
> Checked out revision 2.
> + svn checkout file:tmp/reflective-merge/repos/branch1
> reflective-merge/branch1
> Areflective-merge/branch1/A
> Checked out revision 2.
> + echo foo
> + >> reflective-merge/branch1/A
> + svn commit -m modify A on branch reflective-merge/branch1
> Sendingreflective-merge/branch1/A
> Transmitting file data .
> Committed revision 3.
> + svn mkdir reflective-merge/trunk/folderb
> A reflective-merge/trunk/folderb
> + echo bar
> + >> reflective-merge/trunk/folderb/fileb
> + svn commit -m add folderb/fileb on trunk reflective-merge/trunk
> Adding reflective-merge/trunk/folderb
>
> Committed revision 4.
> + svn update reflective-merge/branch1
> Updating 'reflective-merge/branch1':
> At revision 4.
> + svn merge file:tmp/reflective-merge/repos/trunk
> reflective-merge/branch1 --accept postpone
> --- Merging r2 through r4 into 'reflective-merge/branch1':
> Areflective-merge/branch1/folderb
> --- Recording mergeinfo for merge of r2 through r4 into
> 'reflective-merge/branch1':
>  U   reflective-merge/branch1
> + svn commit reflective-merge/branch1 -m merge trunk into branch (no
> conflicts)
> Sendingreflective-merge/branch1
> Adding reflective-merge/branch1/folderb
>
> Committed revision 5.
> + echo baz
> + >> reflective-merge/branch1/folderb/fileb
> + svn commit -m modify folderb/fileb on branch reflective-merge/branch1
> + svn update reflective-merge/trunk
> Updating 'reflective-merge/trunk':
> At revision 5.
> + svn merge --reintegrate file:tmp/reflective-merge/repos/branch1
> reflective-merge/trunk --accept postpone
> --- Merging differences between repository URLs into
> 'reflective-merge/trunk':
> Ureflective-merge/trunk/A
> --- Recording mergeinfo for merge between repository URLs into
> 'reflective-merge/trunk':
>  U   reflective-merge/trunk
> + svn commit reflective-merge/trunk -m reintegrate branch into trunk (no
> conflicts)
> Sendingreflective-merge/trunk
> Sendingreflective-merge/trunk/A
> Transmitting file data .
> Committed revision 6.
>
> You only get a tree-conflict if you forget to use --reintegrate in the last
> merge:
>
> + svn update reflective-merge/trunk
> Updating 'reflective-merge/trunk':
> At revision 5.
> + svn merge file:tmp/reflective-merge/repos/branch1
> reflective-merge/trunk --accept postpone
> --- Merging r2 through r5 into 'reflective-merge/trunk':
> Ureflective-merge/trunk/A
>   C reflective-merge/trunk/folderb
> --- Recording mergeinfo for merge of r2 through r5 into
> 'reflective-merge/trunk':
>  U   reflective-merge/trunk

Re: small feature request: when checkout/update print out svn:external addresses

[Geoff Hoffman]

On Fri, Dec 9, 2011 at 5:24 AM, Stefan Sperling  wrote:

> On Fri, Dec 09, 2011 at 07:10:41AM +, Cooke, Mark wrote:
> > I don't use the command line much but could you not plit it over three
> lines?
> > {{{
> > Fetching external item:
> >  from : '...'
> >  into : '...'
> > }}}
>
> I like this idea.
>

Me too!

RE: Question

[Bob Archer]

> On 8 December 2011 18:10, Stefan Sperling  wrote:
> On Thu, Dec 08, 2011 at 10:15:24AM -0700, Randall Reynolds wrote:
> > When I select merge a range of revisions and leave the range blank, it says:
> >
> > Merging r7 through 42194
> > <~10 tree conflicts on main folders>
> >
> > Does this mean we have never merged the trunk into the branch
> > correctly in a way that merge tracking recognizes, and how should I
> > proceed to fix the issue?
> It's possible that your server isn't new enough to support merge-tracking.
> What version of Subversion is running on the server?
> The minimum server version for merge-tracking is 1.5.
> Your client should also at least be a 1.5 version and preferably 1.7.
> 
> Another way this can happen is if you fail to commit the svn:mergeinfo
> property the Subversion client creates during a merge.
> 
> If you know the revision range you've already merged but failed to record you
> can run the same merge as a 'record-only' merge. Tortoisesvn has a checkbox
> for this in the merge dialog somewhere. A record-only merge will create the
> svn:mergeinfo property but not actually merge any changes to working files. Of
> course you must make sure that whatever revisions you merge as record-only
> have already been merged. Else you're likely to encounter more merging
> troubles down the road.
> 
> BTW, the more common use case for record-only merges is to block revisions
> you don't want to merge by marking them as already merged, see
> http://svnbook.red-
> bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced
> .blockchanges

> I have been looking through this thread and it might be resolved.
> 
> Can I ask why you are trying to merge from trunk into the branch?  The usual
> operation would be the other way around, otherwise you can run into reflective
> merge issues.
> 
> Rob

It really depends on what type of branch it is. For a feature branch or 
developer branch you want to contantly merge from trunk to branch to keep your 
branch up to do to ensure your changes aren't conflicting with what is 
happening on trunk.

If you are doing release branches and fixing issues on that release branch that 
you want to move back to trunk, then you would merge from branch back to trunk. 
Perhaps this is your branching strategy.

Or perhaps you weren't aware of the new reintegration merge that was added in 
1.5 and are just doing traditional two tree merges from a feature branch back 
to trunk.

We use both feature branches and release branches. However, we don't use a 
single "trunk" since we found it too cumbersome and also had some other issue 
since our build scripts rely on file dates.

BOb

Re: Question

[Stefan Sperling]

On Fri, Dec 09, 2011 at 07:06:10AM -0700, Randall Reynolds wrote:
> Little tangent here, but FWIW I found that the version on the server
> supported merge tracking so it was super wierd that the whole codebase
> reported tree conflicts.  I think we merged incorrectly a long time ago and
> this might have caused the conflicts.  I just rebranched, problem solved,
> next step need to make sure we're merging correctly.

Feel free to ask about use cases you're having trouble with.

Providing this list with a small transcript of a merge you're trying
to run and having problems with is a good way of verifying that you're
driving the tool correctly. Most cases I've heard people complain about
really boil down to user errors. But there are some cases where the tool
flags spurious tree conflicts even though the user has done the right
thing. So sometimes it's not easy to tell. But we're glad to help :)

We're also working towards getting less spurious conflicts flagged with
each release. I am somewhat hopeful 1.8 will make a huge leap in this area.
There is some good stuff in progress but it's too early to tell how much of
it will end up in the final 1.8 release at this point. To that end, we're
very interested in any use cases you have trouble with to help us understand
what matters most to Subversion users in practice. Thanks!

Re: Question

[Randall Reynolds]

Little tangent here, but FWIW I found that the version on the server
supported merge tracking so it was super wierd that the whole codebase
reported tree conflicts.  I think we merged incorrectly a long time ago and
this might have caused the conflicts.  I just rebranched, problem solved,
next step need to make sure we're merging correctly.

On Fri, Dec 9, 2011 at 7:00 AM, Stefan Sperling  wrote:

> On Fri, Dec 09, 2011 at 01:05:02PM +, Rob Pointer wrote:
> > Mark
> > If you put changes multiple times from trunk to a branch (in development
> > terms, a re-base) you can cause reflective merges and actually cause more
> > problems.  The recommended merge back into trunk is a reintegrate merge.
> > I am not sure if this has been addressed in 1.7, but  certainly for
> earlier
> > versions (anyone please correct me if I am wrong here though :) ).
> >
> > The scenario goes
> > 1) trunk contains file A
> > 2) copy trunk to branch1
> > 3) modify file A in branch1
> > 4) add folderb/fileb in trunk
> > 5) branch (copy) folderb into branch (or merge if it actually works :) )
> > 6) do some changes to file A and ffileb
> > 7) merge back into trunk.
> >
> > SVN seems to get confused and when it checks the history of both trunk
> and
> > branch1 it doesn't know that the folderb/fileb was added in branch1
> using a
> > copy, therefore it just thinks you added the files on trunk and then
> > branch1 as two separate operations (for any clearcase users this is an
> evil
> > twin scenario).  Therefore SVN will create a tree conflict when merging
> > your branch back into trunk.
>
> Wrong, wrong, wrong. You may believe that Subversion is broken but in
> fact you're just pushing its buttons the wrong way.
>
> To be clear, if you use the correct merge syntax for each step your
> scenario works just fine. And this applies to 1.6 as well as 1.7.
>
> To demonstrate:
>
> + rm -rf reflective-merge
> + mkdir -p reflective-merge
> + mkdir -p reflective-merge/trunk
> + echo A
> + > reflective-merge/trunk/A
> + svnadmin create /tmp/reflective-merge/repos
> + svn import reflective-merge/trunk
> file:tmp/reflective-merge/repos/trunk -m importing project tree
> Adding reflective-merge/trunk/A
>
> Committed revision 1.
> + svn copy file:tmp/reflective-merge/repos/trunk
> file:tmp/reflective-merge/repos/branch1 -m creating branch
>
> Committed revision 2.
> + rm -rf reflective-merge/trunk
> + svn checkout file:tmp/reflective-merge/repos/trunk
> reflective-merge/trunk
> Areflective-merge/trunk/A
> Checked out revision 2.
> + svn checkout file:tmp/reflective-merge/repos/branch1
> reflective-merge/branch1
> Areflective-merge/branch1/A
> Checked out revision 2.
> + echo foo
> + >> reflective-merge/branch1/A
> + svn commit -m modify A on branch reflective-merge/branch1
> Sendingreflective-merge/branch1/A
> Transmitting file data .
> Committed revision 3.
> + svn mkdir reflective-merge/trunk/folderb
> A reflective-merge/trunk/folderb
> + echo bar
> + >> reflective-merge/trunk/folderb/fileb
> + svn commit -m add folderb/fileb on trunk reflective-merge/trunk
> Adding reflective-merge/trunk/folderb
>
> Committed revision 4.
> + svn update reflective-merge/branch1
> Updating 'reflective-merge/branch1':
> At revision 4.
> + svn merge file:tmp/reflective-merge/repos/trunk
> reflective-merge/branch1 --accept postpone
> --- Merging r2 through r4 into 'reflective-merge/branch1':
> Areflective-merge/branch1/folderb
> --- Recording mergeinfo for merge of r2 through r4 into
> 'reflective-merge/branch1':
>  U   reflective-merge/branch1
> + svn commit reflective-merge/branch1 -m merge trunk into branch (no
> conflicts)
> Sendingreflective-merge/branch1
> Adding reflective-merge/branch1/folderb
>
> Committed revision 5.
> + echo baz
> + >> reflective-merge/branch1/folderb/fileb
> + svn commit -m modify folderb/fileb on branch reflective-merge/branch1
> + svn update reflective-merge/trunk
> Updating 'reflective-merge/trunk':
> At revision 5.
> + svn merge --reintegrate file:tmp/reflective-merge/repos/branch1
> reflective-merge/trunk --accept postpone
> --- Merging differences between repository URLs into
> 'reflective-merge/trunk':
> Ureflective-merge/trunk/A
> --- Recording mergeinfo for merge between repository URLs into
> 'reflective-merge/trunk':
>  U   reflective-merge/trunk
> + svn commit reflective-merge/trunk -m reintegrate branch into trunk (no
> conflicts)
> Sendingreflective-merge/trunk
> Sendingreflective-merge/trunk/A
> Transmitting file data .
> Committed revision 6.
>
> You only get a tree-conflict if you forget to use --reintegrate in the last
> merge:
>
> + svn update reflective-merge/trunk
> Updating 'reflective-merge/trunk':
> At revision 5.
> + svn merge file:tmp/reflective-merge/repos/branch1
> reflective-merge/trunk --accept postpone
> --- Merging r2 through r5 into 'reflective-merge/trunk':
> Ureflective-merge/trunk/A
>   

Re: Question

[Stefan Sperling]

On Fri, Dec 09, 2011 at 01:05:02PM +, Rob Pointer wrote:
> Mark
> If you put changes multiple times from trunk to a branch (in development
> terms, a re-base) you can cause reflective merges and actually cause more
> problems.  The recommended merge back into trunk is a reintegrate merge.
> I am not sure if this has been addressed in 1.7, but  certainly for earlier
> versions (anyone please correct me if I am wrong here though :) ).
> 
> The scenario goes
> 1) trunk contains file A
> 2) copy trunk to branch1
> 3) modify file A in branch1
> 4) add folderb/fileb in trunk
> 5) branch (copy) folderb into branch (or merge if it actually works :) )
> 6) do some changes to file A and ffileb
> 7) merge back into trunk.
> 
> SVN seems to get confused and when it checks the history of both trunk and
> branch1 it doesn't know that the folderb/fileb was added in branch1 using a
> copy, therefore it just thinks you added the files on trunk and then
> branch1 as two separate operations (for any clearcase users this is an evil
> twin scenario).  Therefore SVN will create a tree conflict when merging
> your branch back into trunk.

Wrong, wrong, wrong. You may believe that Subversion is broken but in
fact you're just pushing its buttons the wrong way.

To be clear, if you use the correct merge syntax for each step your
scenario works just fine. And this applies to 1.6 as well as 1.7.

To demonstrate:

+ rm -rf reflective-merge
+ mkdir -p reflective-merge
+ mkdir -p reflective-merge/trunk
+ echo A
+ > reflective-merge/trunk/A 
+ svnadmin create /tmp/reflective-merge/repos
+ svn import reflective-merge/trunk file:tmp/reflective-merge/repos/trunk 
-m importing project tree
Adding reflective-merge/trunk/A

Committed revision 1.
+ svn copy file:tmp/reflective-merge/repos/trunk 
file:tmp/reflective-merge/repos/branch1 -m creating branch

Committed revision 2.
+ rm -rf reflective-merge/trunk
+ svn checkout file:tmp/reflective-merge/repos/trunk reflective-merge/trunk
Areflective-merge/trunk/A
Checked out revision 2.
+ svn checkout file:tmp/reflective-merge/repos/branch1 
reflective-merge/branch1
Areflective-merge/branch1/A
Checked out revision 2.
+ echo foo
+ >> reflective-merge/branch1/A 
+ svn commit -m modify A on branch reflective-merge/branch1
Sendingreflective-merge/branch1/A
Transmitting file data .
Committed revision 3.
+ svn mkdir reflective-merge/trunk/folderb
A reflective-merge/trunk/folderb
+ echo bar
+ >> reflective-merge/trunk/folderb/fileb 
+ svn commit -m add folderb/fileb on trunk reflective-merge/trunk
Adding reflective-merge/trunk/folderb

Committed revision 4.
+ svn update reflective-merge/branch1
Updating 'reflective-merge/branch1':
At revision 4.
+ svn merge file:tmp/reflective-merge/repos/trunk reflective-merge/branch1 
--accept postpone
--- Merging r2 through r4 into 'reflective-merge/branch1':
Areflective-merge/branch1/folderb
--- Recording mergeinfo for merge of r2 through r4 into 
'reflective-merge/branch1':
 U   reflective-merge/branch1
+ svn commit reflective-merge/branch1 -m merge trunk into branch (no conflicts)
Sendingreflective-merge/branch1
Adding reflective-merge/branch1/folderb

Committed revision 5.
+ echo baz
+ >> reflective-merge/branch1/folderb/fileb 
+ svn commit -m modify folderb/fileb on branch reflective-merge/branch1
+ svn update reflective-merge/trunk
Updating 'reflective-merge/trunk':
At revision 5.
+ svn merge --reintegrate file:tmp/reflective-merge/repos/branch1 
reflective-merge/trunk --accept postpone
--- Merging differences between repository URLs into 'reflective-merge/trunk':
Ureflective-merge/trunk/A
--- Recording mergeinfo for merge between repository URLs into 
'reflective-merge/trunk':
 U   reflective-merge/trunk
+ svn commit reflective-merge/trunk -m reintegrate branch into trunk (no 
conflicts)
Sendingreflective-merge/trunk
Sendingreflective-merge/trunk/A
Transmitting file data .
Committed revision 6.

You only get a tree-conflict if you forget to use --reintegrate in the last
merge:

+ svn update reflective-merge/trunk
Updating 'reflective-merge/trunk':
At revision 5.
+ svn merge file:tmp/reflective-merge/repos/branch1 reflective-merge/trunk 
--accept postpone
--- Merging r2 through r5 into 'reflective-merge/trunk':
Ureflective-merge/trunk/A
   C reflective-merge/trunk/folderb
--- Recording mergeinfo for merge of r2 through r5 into 
'reflective-merge/trunk':
 U   reflective-merge/trunk
Summary of conflicts:
  Tree conflicts: 1
+ svn commit reflective-merge/trunk -m reintegrate branch into trunk (no 
conflicts)
subversion/svn/commit-cmd.c:183: (apr_err=155015)
subversion/libsvn_client/commit.c:853: (apr_err=155015)
subversion/libsvn_client/commit.c:853: (apr_err=155015)
svn: E155015: Commit failed (details follow):
subversion/libsvn_client/commit_util.c:1154: (apr_err=155015)
subversion/libsvn_client/commit_util.c:1154: (apr_err=155015)
subversion/libsv

Re: Question

[Rob Pointer]

Let me explain my reasoning.

My thinking is that if you are trying to merge from trunk to branch, then
you are doing things the wrong way around, because if you copy out from
trunk, you merge back into trunk.

The other issue may be that If you copy from trunk more than once to the
same branch (from trunk) at different revisions, then try to merge back you
will likely get reflective merge issues.  This is because SVN actually
tries to track the changes back.  In this case you would need to do a
reintegrate merge.  But from your explanation you are just doing copy, add
copy. Or have you actually copied more than once from trunk to the branch?
When you look at the merge conflicts, are they for for folders/files that
existed in trunk before the copy?  If so they I really think you are doing
teh merge the wrong way around :)

I am therefore still concerned about your terminology of merging FROM trunk
INTO branch. It should most definitely be FROM branch INTO trunk.  (excuse
the caps, I don't have the ability from here to make my text bold :) )

Rob

On 9 December 2011 12:44, Rob Pointer  wrote:

> I have been looking through this thread and it might be resolved.
>
> Can I ask why you are trying to merge from trunk into the branch?  The
> usual operation would be the other way around, otherwise you can run into
> reflective merge issues.
>
> Rob
>
>
> On 8 December 2011 18:10, Stefan Sperling  wrote:
>
>> On Thu, Dec 08, 2011 at 10:15:24AM -0700, Randall Reynolds wrote:
>> > When I select merge a range of revisions and leave the range blank, it
>> says:
>> >
>> > Merging r7 through 42194
>> > <~10 tree conflicts on main folders>
>> >
>> > Does this mean we have never merged the trunk into the branch correctly
>> in
>> > a way that merge tracking recognizes, and how should I proceed to fix
>> the
>> > issue?
>>
>> It's possible that your server isn't new enough to support merge-tracking.
>> What version of Subversion is running on the server?
>> The minimum server version for merge-tracking is 1.5.
>> Your client should also at least be a 1.5 version and preferably 1.7.
>>
>> Another way this can happen is if you fail to commit the svn:mergeinfo
>> property the Subversion client creates during a merge.
>>
>> If you know the revision range you've already merged but failed to record
>> you can run the same merge as a 'record-only' merge. Tortoisesvn has a
>> checkbox for this in the merge dialog somewhere. A record-only merge will
>> create the svn:mergeinfo property but not actually merge any changes to
>> working files. Of course you must make sure that whatever revisions you
>> merge as record-only have already been merged. Else you're likely to
>> encounter more merging troubles down the road.
>>
>> BTW, the more common use case for record-only merges is to block revisions
>> you don't want to merge by marking them as already merged, see
>>
>> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges
>>
>
>
>
> --
> *Rob Pointer MSc*
> Software Specialist and Consultant
> rpoin...@clearvision-cm.com 
>
> *
> Tel: +44 (0) 845 459 9530
>  **
> **
>   
> 
>    
> 
>   
> *
>
>
>


-- 
*Rob Pointer MSc*
Software Specialist and Consultant
rpoin...@clearvision-cm.com 

*
Tel: +44 (0) 845 459 9530
**
**
 
  

  
*

Re: Question

[Rob Pointer]

Mark
If you put changes multiple times from trunk to a branch (in development
terms, a re-base) you can cause reflective merges and actually cause more
problems.  The recommended merge back into trunk is a reintegrate merge.
I am not sure if this has been addressed in 1.7, but  certainly for earlier
versions (anyone please correct me if I am wrong here though :) ).

The scenario goes
1) trunk contains file A
2) copy trunk to branch1
3) modify file A in branch1
4) add folderb/fileb in trunk
5) branch (copy) folderb into branch (or merge if it actually works :) )
6) do some changes to file A and ffileb
7) merge back into trunk.

SVN seems to get confused and when it checks the history of both trunk and
branch1 it doesn't know that the folderb/fileb was added in branch1 using a
copy, therefore it just thinks you added the files on trunk and then
branch1 as two separate operations (for any clearcase users this is an evil
twin scenario).  Therefore SVN will create a tree conflict when merging
your branch back into trunk.
A similar scenario occurs of you copied file A from trunk to branch1 after
modifying it on trunk.  SVN will then throw content conflicts, telling you
that you modified the same line in the file  in two branches (i.e. trunk
and branch1) and the text is identical.  Again not sure if 1.7 fixes this,
but it is definitely present in 1.6.x

Rob

On 9 December 2011 12:49, Cooke, Mark  wrote:

>
>
> > -Original Message-
> > From: Rob Pointer [mailto:rpoin...@clearvision-cm.com]
> > Sent: 09 December 2011 12:45
> > To: Randall Reynolds; Cooke, Mark; users@subversion.apache.org
> > Subject: Re: Question
> >
> > I have been looking through this thread and it might be resolved.
> >
> > Can I ask why you are trying to merge from trunk into the
> > branch?  The usual operation would be the other way around,
> > otherwise you can run into reflective merge issues.
>
> Really?  My understanding is that most merges are from trunk to branch to
> keep the branch up to date so that when you reintegrate back to trunk you
> hit less issues...
>
> ~ mark c
>
> > Rob
>



-- 
*Rob Pointer MSc*
Software Specialist and Consultant
rpoin...@clearvision-cm.com 

*
Tel: +44 (0) 845 459 9530
**
**
 
  

  
*

Re: Question

[Rob Pointer]

I have been looking through this thread and it might be resolved.

Can I ask why you are trying to merge from trunk into the branch?  The
usual operation would be the other way around, otherwise you can run into
reflective merge issues.

Rob

On 8 December 2011 18:10, Stefan Sperling  wrote:

> On Thu, Dec 08, 2011 at 10:15:24AM -0700, Randall Reynolds wrote:
> > When I select merge a range of revisions and leave the range blank, it
> says:
> >
> > Merging r7 through 42194
> > <~10 tree conflicts on main folders>
> >
> > Does this mean we have never merged the trunk into the branch correctly
> in
> > a way that merge tracking recognizes, and how should I proceed to fix the
> > issue?
>
> It's possible that your server isn't new enough to support merge-tracking.
> What version of Subversion is running on the server?
> The minimum server version for merge-tracking is 1.5.
> Your client should also at least be a 1.5 version and preferably 1.7.
>
> Another way this can happen is if you fail to commit the svn:mergeinfo
> property the Subversion client creates during a merge.
>
> If you know the revision range you've already merged but failed to record
> you can run the same merge as a 'record-only' merge. Tortoisesvn has a
> checkbox for this in the merge dialog somewhere. A record-only merge will
> create the svn:mergeinfo property but not actually merge any changes to
> working files. Of course you must make sure that whatever revisions you
> merge as record-only have already been merged. Else you're likely to
> encounter more merging troubles down the road.
>
> BTW, the more common use case for record-only merges is to block revisions
> you don't want to merge by marking them as already merged, see
>
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges
>



-- 
*Rob Pointer MSc*
Software Specialist and Consultant
rpoin...@clearvision-cm.com 

*
Tel: +44 (0) 845 459 9530
**
**
 
  

  
*

RE: Question

[Cooke, Mark]

 

> -Original Message-
> From: Rob Pointer [mailto:rpoin...@clearvision-cm.com] 
> Sent: 09 December 2011 12:45
> To: Randall Reynolds; Cooke, Mark; users@subversion.apache.org
> Subject: Re: Question
> 
> I have been looking through this thread and it might be resolved. 
> 
> Can I ask why you are trying to merge from trunk into the 
> branch?  The usual operation would be the other way around, 
> otherwise you can run into reflective merge issues.

Really?  My understanding is that most merges are from trunk to branch to keep 
the branch up to date so that when you reintegrate back to trunk you hit less 
issues...

~ mark c

> Rob

Re: small feature request: when checkout/update print out svn:external addresses

[Stefan Sperling]

On Fri, Dec 09, 2011 at 07:10:41AM +, Cooke, Mark wrote:
> I don't use the command line much but could you not plit it over three lines?
> {{{
> Fetching external item:
>  from : '...'
>  into : '...'
> }}}

I like this idea.

Re: small feature request: when checkout/update print out svn:external addresses

[Daniel Shahaf]

Daniel Shahaf wrote on Fri, Dec 09, 2011 at 09:06:38 +0200:
> How would you avoid overflowing the terminal width when the external's
> URL is absolute?
> 

To answer my own question: only print the absolute URL of an external
when the property specifies a relative external.

> Dmitry Bolshakov wrote on Thu, Dec 08, 2011 at 18:25:38 +0400:
> > Hi
> > 
> > not long ago we have made some reorganization in repository, but forgot to 
> > make svn:external relative instead of absolute
> > and I was really confused when build errors surprizingly appeared in an 
> > unchanged tags
> > 
> > so I think it would be useful to print out external addresses too
> > eg not just
> > "Fetching external item into '...'"
> > but
> > "Fetching external item from '...' into '...'"
> > 
> > it will allow to recognize such errors easily
> > 
> > -- 
> > With best regards
> > Dmitry Bolshakov

Re: small feature request: when checkout/update print out svn:external addresses

[Dmitry Bolshakov]

imho the log completeness is more important then pretty view
all the more so as most modern displays are widescreen
why the width is an issue?

 Original Message  
Subject: Re: small feature request: when checkout/update print out svn:external 
addresses
From: Daniel Shahaf 
To: Dmitry Bolshakov 
Cc: users@subversion.apache.org
Date: 09.12.2011 11:06


How would you avoid overflowing the terminal width when the external's
URL is absolute?

Dmitry Bolshakov wrote on Thu, Dec 08, 2011 at 18:25:38 +0400:

Hi

not long ago we have made some reorganization in repository, but forgot to make 
svn:external relative instead of absolute
and I was really confused when build errors surprizingly appeared in an 
unchanged tags

so I think it would be useful to print out external addresses too
eg not just
"Fetching external item into '...'"
but
"Fetching external item from '...' into '...'"

it will allow to recognize such errors easily

--
With best regards
Dmitry Bolshakov





--
With best regards
Dmitry Bolshakov

Re: Python-subversion

[Daniel Shahaf]

Marc Schlinger wrote on Fri, Dec 09, 2011 at 10:02:16 +0100:
> Le jeudi 08 décembre 2011 à 19:39 +0200, Daniel Shahaf a écrit :
> > Marc Schlinger wrote on Thu, Dec 08, 2011 at 16:00:03 +0100:
> > > Le jeudi 08 décembre 2011 à 15:20 +0200, Daniel Shahaf a écrit :
> > > > Marc Schlinger wrote on Thu, Dec 08, 2011 at 14:07:06 +0100:
> > > > > Hello,
> > > > > 
> > > > > I'm using subversion and python-subversion on a debian squeeze system.
> > > > > The package version is 1.6.12dfsg-4.
> > > > > 
> > > > > I'm trying to modify the behavior of the changed command of the
> > > > > svnlook.py file provided by python-subversion.
> > > > > 
> > > > > I'm want to show that a directory was copied by adding a "+" to the
> > > > > output - the way genuine svnlook command do.
> > > > > 
> > > > > I've modified the add_directory method of the ChangedEditor as follow:
> > > > > 
> > > > >   def add_directory(self, path, parent_baton,
> > > > > copyfrom_path, copyfrom_revision, dir_pool):
> > > > > 
> > > > > print('A %s %s/' % ("+" if copyfrom_path else " ", path))
> > > > > return [ 0, path ]
> > > > > 
> > > > > but the copyfrom_path always equals to None.
> > > > > 
> > > > > Is there a way to have this parameter set?
> > > > > 
> > > > 
> > > > What does viewvc do to cause
> > > > http://svn.apache.org/viewvc?view=revision&revision=1207555
> > > > to show "(Copied from
> > > > subversion/trunk/contrib/server-side/mod_dontdothat, r1207550)"
> > > > ?
> > > 
> > > Thanks for pointing out this project. I didn't even notice it was
> > > written in python.
> > > 
> > > To answer your question.
> > > They call the svn.fs.copied_from(rev_root, path) method to get the
> > > copyfrom_path information.
> > > 
> > > They don't seem to implement the "editor" interface, so I still don't
> > > know how to get the copyfrom_info directly in add_directory.
> > 
> > Perhaps you should use svn_repos_replay() to drive your editor?
> > 
> That's excatly what I've found in svnlook::main.c . They use
> svn_repos_replay2.
> In python it's in the subpackage repos of package svn.
> 
> The right method to use is svn.repos.replay2 because the api have
> changed.
> 
> http://subversion.apache.org/docs/api/1.6/svn__repos_8h.html#aef0fa3335d10b603cfbae5efc7a5d016
> 

Yes.  If being able to run against the 1.3 libraries isn't important to
you then you should use svn_repos_replay2() instead of svn_repos_replay().

> Since python subversion is an "dummy" binding of the subversion C api I
> think this is the right place to look at.
> 

Yes.  Note that there are also ctypes python bindings which have
a portino which is not "dummy".

> 
> Thank you for your help.
> 
> 
> > A quick look into the source of svn_repos_dir_delta2() (which is what
> > 'svnlook.py changed' uses) suggests that it always passes '(NULL,
> > SVN_INVALID_REVNUM)' for the copyfrom.
> > 
> > 
> >  Click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==  to report 
> > this email as spam.
> 
> 
> 
> This message has been scanned for viruses by BlackSpider MailControl. - 
> www.blackspider.com

Re: Python-subversion

[Marc Schlinger]

Le jeudi 08 décembre 2011 à 19:39 +0200, Daniel Shahaf a écrit :
> Marc Schlinger wrote on Thu, Dec 08, 2011 at 16:00:03 +0100:
> > Le jeudi 08 décembre 2011 à 15:20 +0200, Daniel Shahaf a écrit :
> > > Marc Schlinger wrote on Thu, Dec 08, 2011 at 14:07:06 +0100:
> > > > Hello,
> > > > 
> > > > I'm using subversion and python-subversion on a debian squeeze system.
> > > > The package version is 1.6.12dfsg-4.
> > > > 
> > > > I'm trying to modify the behavior of the changed command of the
> > > > svnlook.py file provided by python-subversion.
> > > > 
> > > > I'm want to show that a directory was copied by adding a "+" to the
> > > > output - the way genuine svnlook command do.
> > > > 
> > > > I've modified the add_directory method of the ChangedEditor as follow:
> > > > 
> > > >   def add_directory(self, path, parent_baton,
> > > > copyfrom_path, copyfrom_revision, dir_pool):
> > > > 
> > > > print('A %s %s/' % ("+" if copyfrom_path else " ", path))
> > > > return [ 0, path ]
> > > > 
> > > > but the copyfrom_path always equals to None.
> > > > 
> > > > Is there a way to have this parameter set?
> > > > 
> > > 
> > > What does viewvc do to cause
> > > http://svn.apache.org/viewvc?view=revision&revision=1207555
> > > to show "(Copied from
> > > subversion/trunk/contrib/server-side/mod_dontdothat, r1207550)"
> > > ?
> > 
> > Thanks for pointing out this project. I didn't even notice it was
> > written in python.
> > 
> > To answer your question.
> > They call the svn.fs.copied_from(rev_root, path) method to get the
> > copyfrom_path information.
> > 
> > They don't seem to implement the "editor" interface, so I still don't
> > know how to get the copyfrom_info directly in add_directory.
> 
> Perhaps you should use svn_repos_replay() to drive your editor?
> 
That's excatly what I've found in svnlook::main.c . They use
svn_repos_replay2.
In python it's in the subpackage repos of package svn.

The right method to use is svn.repos.replay2 because the api have
changed.

http://subversion.apache.org/docs/api/1.6/svn__repos_8h.html#aef0fa3335d10b603cfbae5efc7a5d016

Since python subversion is an "dummy" binding of the subversion C api I
think this is the right place to look at.


Thank you for your help.


> A quick look into the source of svn_repos_dir_delta2() (which is what
> 'svnlook.py changed' uses) suggests that it always passes '(NULL,
> SVN_INVALID_REVNUM)' for the copyfrom.
> 
> 
>  Click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==  to report 
> this email as spam.



This message has been scanned for viruses by BlackSpider MailControl. - 
www.blackspider.com