Re: merge using same revision number - quick question

[Z W]

On Wed, Apr 24, 2013 at 6:16 PM, Branko Čibej  wrote:

> On 24.04.2013 23:06, Z W wrote:
> >
> >
> >
> > On Wed, Apr 24, 2013 at 1:42 PM, Mark Phippard  > > wrote:
> >
> > On Wed, Apr 24, 2013 at 4:40 PM, Bob Archer  > > wrote:
> > > Please check the poperties on one of the files. Tell me what the
> > mergeinfo: is prior to your merge
> > > and after your merge. Up to this point we were talking about
> > generalities, but we are getting down to specifics now.
> >
> > FWIW, after running the merge just run svn diff.  It will show the
> > changes it made to the properties.
> >
> >
> > Hi Mark thanks for responding too.
> > We are trying to automate this process for many files.
> > We simply merge and commit until we hit a Conflict.
>
> A note about process here ... It is in general not a good idea to
> automate the commit step. Merge results should always be reviewed. If
> Subversion does not flag a conflict that does /not/ mean that the merge
> is semantically correct (or even syntactically, if we're talking about
> merging source code); it only means that it did not find conflicting
> regions of changes in the text.
>
> There is no guarantee that a conflict-less merge results in valid code.
> If you're lucky, a compiler will flag the problem; if not, you might
> find out when users raise support tickets.
>
> -- Brane
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
>
> Hi Branko

Thanks for responding and the heads up.

Sincerely

Re: merge using same revision number - quick question

[Branko Čibej]

On 24.04.2013 23:06, Z W wrote:
>
>
>
> On Wed, Apr 24, 2013 at 1:42 PM, Mark Phippard  > wrote:
>
> On Wed, Apr 24, 2013 at 4:40 PM, Bob Archer  > wrote:
> > Please check the poperties on one of the files. Tell me what the
> mergeinfo: is prior to your merge
> > and after your merge. Up to this point we were talking about
> generalities, but we are getting down to specifics now.
>
> FWIW, after running the merge just run svn diff.  It will show the
> changes it made to the properties.
>
>
> Hi Mark thanks for responding too.
> We are trying to automate this process for many files.
> We simply merge and commit until we hit a Conflict.

A note about process here ... It is in general not a good idea to
automate the commit step. Merge results should always be reviewed. If
Subversion does not flag a conflict that does /not/ mean that the merge
is semantically correct (or even syntactically, if we're talking about
merging source code); it only means that it did not find conflicting
regions of changes in the text.

There is no guarantee that a conflict-less merge results in valid code.
If you're lucky, a compiler will flag the problem; if not, you might
find out when users raise support tickets.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: merge using same revision number - quick question

[Johan Corveleyn]

On Wed, Apr 24, 2013 at 11:06 PM, Z W  wrote:
>
>
>
> On Wed, Apr 24, 2013 at 1:42 PM, Mark Phippard  wrote:
>>
>> On Wed, Apr 24, 2013 at 4:40 PM, Bob Archer  wrote:
>> > Please check the poperties on one of the files. Tell me what the
>> > mergeinfo: is prior to your merge
>> > and after your merge. Up to this point we were talking about
>> > generalities, but we are getting down to specifics now.
>>
>> FWIW, after running the merge just run svn diff.  It will show the
>> changes it made to the properties.
>>
>
> Hi Mark thanks for responding too.
> We are trying to automate this process for many files.
> We simply merge and commit until we hit a Conflict.
>

Here is an interesting thread from a couple months back, about subtree
mergeinfo and how elision currently works:

http://svn.haxx.se/users/archive-2012-09/0201.shtml

I suggest you read it entirely, it contains a lot of useful information.

It's possible that elision (automatically removing the superfluous
subtree mergeinfo) won't work in your case. But even if it doesn't,
you shouldn't worry too much about it. As others have said: if you use
1.7 clients, merges will be much less chatty (won't touch the subtree
mergeinfo, unless the merge actually changes something there).

--
Johan

Re: merge using same revision number - quick question

[Z W]

On Wed, Apr 24, 2013 at 1:42 PM, Mark Phippard  wrote:

> On Wed, Apr 24, 2013 at 4:40 PM, Bob Archer  wrote:
> > Please check the poperties on one of the files. Tell me what the
> mergeinfo: is prior to your merge
> > and after your merge. Up to this point we were talking about
> generalities, but we are getting down to specifics now.
>
> FWIW, after running the merge just run svn diff.  It will show the
> changes it made to the properties.
>
>
Hi Mark thanks for responding too.
We are trying to automate this process for many files.
We simply merge and commit until we hit a Conflict.


> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>

Re: merge using same revision number - quick question

[Z W]

On Wed, Apr 24, 2013 at 1:40 PM, Bob Archer  wrote:

> > -Original Message-
> > From: Z W [mailto:mpc8...@gmail.com]
> > Sent: Wednesday, April 24, 2013 4:26 PM
> > To: Bob Archer
> > Cc: Johan Corveleyn; users@subversion.apache.org
> > Subject: Re: merge using same revision number - quick question
> >
> >
> >
> > On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer  wrote:
> > > On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer 
> > wrote:
> > > > Hi Johan, Bob and all
> > > >
> > > > We took your suggestion and it still fails in that
> > > > 1- when we try to merge again at the root level
> > > > (goals:
> > > > a- to move subtree merge done previously to the working copy root
> > > > level so that the past merge can be traced at the root level using
> > > > "svn mergeinfo -show- revs merged)
> > > >
> > > > svn merge -c 498 https://test.com/svn/root /path/to/root
> > > >
> > > > But when we do a svn status, all other untouched files and folders
> > > > (unrelated to the revision number) are also touched.
> > > >
> > > > svn status -u
> > > > M   506 src/ap
> > > > M   506 src/ap/k.java
> > > > :
> > > > :
> > > >
> > > > We then commit.
> > > >
> > > > We performed the above steps for several other revision numbers and
> > > > still get the same svn status -u output for those files and folders
> > > > when executing those other subsequent revision numbers.
> > > >
> > > >
> > > > What are we doing wrong ?
> > > What are the changes to those files? I assume mergeinfo is being
> > > elided from all those files? If so, that is something that you want to
> > > happen. Once that is done the first time, all your merge info will be
> > > in the root folder and you won't see this any more.
> >
> > Hi Bob, we're still seeing the problem of unwanted touches of files and
> > directories on new unmerged rev numbers, even after we reapply all merges
> > for all previous already-merged at feature branch root level.
> > We're getting concerned now, wondering if we misunderstood the
> explanations
> > here.
> > We're using SVN 1.6
>
>
> Please check the poperties on one of the files. Tell me what the
> mergeinfo: is prior to your merge and after your merge. Up to this point we
> were talking about generalities, but we are getting down to specifics now.
>
>
>> Hi Bob, thanks for taking the time to respond.
do u mean u like us to getprop for mergeinfo ?
if not, how do we get that info you like ?
So far we only messed with
svn mergeinfo --show-rev eligible and merged.



> Also, 1.7 is much less chatty wrt where it adds merge info.
>
> BOb
>
>
> >
> > > Thanks for your response.
> > > What does elided mean ?
> > Elide simple means remove.
> >
> > > We do see the revision numbers are moved from eligible to merged in
> > > svn mergeinfo after a "svn merge" and "svn commit"
> > >
> > Great... if you always do your merges from your project root, you won't
> see this
> > issue again.
> >
> >
>
>

Re: merge using same revision number - quick question

[Z W]

On Wed, Apr 24, 2013 at 1:30 PM, Mark Phippard  wrote:

> On Wed, Apr 24, 2013 at 4:25 PM, Z W  wrote:
>
> > Hi Bob, we're still seeing the problem of unwanted touches of files and
> > directories on new unmerged rev numbers, even after we reapply all merges
> > for all previous already-merged at feature branch root level.
> > We're getting concerned now, wondering if we misunderstood the
> explanations
> > here.
> > We're using SVN 1.6
>
> When you do a merge with an SVN 1.6 client, all paths beneath the
> merge target that have the svn:mergeinfo property set on them will be
> "touched" by the merge.  Something about the mergeinfo on those items
> will always be changed.  Usually it will just be adding the revisions
> merged to the ranges stored in the properties.
>
> With an SVN 1.7 client, merge will only update the mergeinfo for paths
> that were affected by the merge.
>
> I have not followed the thread, but you can probably remove the
> svn:mergeinfo property from these files and just start to be sure you
> only do all future merges from the root of the tree.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>



Hi Mark
Thanks for the response.
We find the mergeinfo property useful in helping us capture all the rev
numbers to merge from trunk to branch at the root level.
so we're not sure if we like to remove it.

Re: merge using same revision number - quick question

[Mark Phippard]

On Wed, Apr 24, 2013 at 4:40 PM, Bob Archer  wrote:
> Please check the poperties on one of the files. Tell me what the mergeinfo: 
> is prior to your merge
> and after your merge. Up to this point we were talking about generalities, 
> but we are getting down to specifics now.

FWIW, after running the merge just run svn diff.  It will show the
changes it made to the properties.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: merge using same revision number - quick question

[Bob Archer]

> -Original Message-
> From: Z W [mailto:mpc8...@gmail.com]
> Sent: Wednesday, April 24, 2013 4:26 PM
> To: Bob Archer
> Cc: Johan Corveleyn; users@subversion.apache.org
> Subject: Re: merge using same revision number - quick question
> 
> 
> 
> On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer  wrote:
> > On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer 
> wrote:
> > > Hi Johan, Bob and all
> > >
> > > We took your suggestion and it still fails in that
> > > 1- when we try to merge again at the root level
> > > (goals:
> > > a- to move subtree merge done previously to the working copy root
> > > level so that the past merge can be traced at the root level using
> > > "svn mergeinfo -show- revs merged)
> > >
> > > svn merge -c 498 https://test.com/svn/root /path/to/root
> > >
> > > But when we do a svn status, all other untouched files and folders
> > > (unrelated to the revision number) are also touched.
> > >
> > > svn status -u
> > > M           506 src/ap
> > > M           506 src/ap/k.java
> > > :
> > > :
> > >
> > > We then commit.
> > >
> > > We performed the above steps for several other revision numbers and
> > > still get the same svn status -u output for those files and folders
> > > when executing those other subsequent revision numbers.
> > >
> > >
> > > What are we doing wrong ?
> > What are the changes to those files? I assume mergeinfo is being
> > elided from all those files? If so, that is something that you want to
> > happen. Once that is done the first time, all your merge info will be
> > in the root folder and you won't see this any more.
> 
> Hi Bob, we're still seeing the problem of unwanted touches of files and
> directories on new unmerged rev numbers, even after we reapply all merges
> for all previous already-merged at feature branch root level.
> We're getting concerned now, wondering if we misunderstood the explanations
> here.
> We're using SVN 1.6


Please check the poperties on one of the files. Tell me what the mergeinfo: is 
prior to your merge and after your merge. Up to this point we were talking 
about generalities, but we are getting down to specifics now.

Also, 1.7 is much less chatty wrt where it adds merge info. 

BOb


> 
> > Thanks for your response.
> > What does elided mean ?
> Elide simple means remove.
> 
> > We do see the revision numbers are moved from eligible to merged in
> > svn mergeinfo after a "svn merge" and "svn commit"
> >
> Great... if you always do your merges from your project root, you won't see 
> this
> issue again.
> 
> 

Re: merge using same revision number - quick question

[Mark Phippard]

On Wed, Apr 24, 2013 at 4:25 PM, Z W  wrote:

> Hi Bob, we're still seeing the problem of unwanted touches of files and
> directories on new unmerged rev numbers, even after we reapply all merges
> for all previous already-merged at feature branch root level.
> We're getting concerned now, wondering if we misunderstood the explanations
> here.
> We're using SVN 1.6

When you do a merge with an SVN 1.6 client, all paths beneath the
merge target that have the svn:mergeinfo property set on them will be
"touched" by the merge.  Something about the mergeinfo on those items
will always be changed.  Usually it will just be adding the revisions
merged to the ranges stored in the properties.

With an SVN 1.7 client, merge will only update the mergeinfo for paths
that were affected by the merge.

I have not followed the thread, but you can probably remove the
svn:mergeinfo property from these files and just start to be sure you
only do all future merges from the root of the tree.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: merge using same revision number - quick question

[Z W]

On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer  wrote:

> > On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer  wrote:
> > > Hi Johan, Bob and all
> > >
> > > We took your suggestion and it still fails in that
> > > 1- when we try to merge again at the root level
> > > (goals:
> > > a- to move subtree merge done previously to the working copy root
> > > level so that the past merge can be traced at the root level using
> > > "svn mergeinfo -show- revs merged)
> > >
> > > svn merge -c 498 https://test.com/svn/root /path/to/root
> > >
> > > But when we do a svn status, all other untouched files and folders
> > > (unrelated to the revision number) are also touched.
> > >
> > > svn status -u
> > > M   506 src/ap
> > > M   506 src/ap/k.java
> > > :
> > > :
> > >
> > > We then commit.
> > >
> > > We performed the above steps for several other revision numbers and
> > > still get the same svn status -u output for those files and folders
> > > when executing those other subsequent revision numbers.
> > >
> > >
> > > What are we doing wrong ?
> > What are the changes to those files? I assume mergeinfo is being elided
> from
> > all those files? If so, that is something that you want to happen. Once
> that is
> > done the first time, all your merge info will be in the root folder and
> you won't
> > see this any more.
>
>
Hi Bob, we're still seeing the problem of unwanted touches of files and
directories on new unmerged rev numbers, even after we reapply all merges
for all previous already-merged at feature branch root level.
We're getting concerned now, wondering if we misunderstood the explanations
here.
We're using SVN 1.6


> > Thanks for your response.
> > What does elided mean ?
>
> Elide simple means remove.
>
> > We do see the revision numbers are moved from eligible to merged in svn
> > mergeinfo after a "svn merge" and "svn commit"
> >
>
> Great... if you always do your merges from your project root, you won't
> see this issue again.
>
>

Re: merge using same revision number - quick question

[Z W]

On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer  wrote:

> > On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer  wrote:
> > > Hi Johan, Bob and all
> > >
> > > We took your suggestion and it still fails in that
> > > 1- when we try to merge again at the root level
> > > (goals:
> > > a- to move subtree merge done previously to the working copy root
> > > level so that the past merge can be traced at the root level using
> > > "svn mergeinfo -show- revs merged)
> > >
> > > svn merge -c 498 https://test.com/svn/root /path/to/root
> > >
> > > But when we do a svn status, all other untouched files and folders
> > > (unrelated to the revision number) are also touched.
> > >
> > > svn status -u
> > > M   506 src/ap
> > > M   506 src/ap/k.java
> > > :
> > > :
> > >
> > > We then commit.
> > >
> > > We performed the above steps for several other revision numbers and
> > > still get the same svn status -u output for those files and folders
> > > when executing those other subsequent revision numbers.
> > >
> > >
> > > What are we doing wrong ?
> > What are the changes to those files? I assume mergeinfo is being elided
> from
> > all those files? If so, that is something that you want to happen. Once
> that is
> > done the first time, all your merge info will be in the root folder and
> you won't
> > see this any more.
>
> > Thanks for your response.
> > What does elided mean ?
>
> Elide simple means remove.
>
> > We do see the revision numbers are moved from eligible to merged in svn
> > mergeinfo after a "svn merge" and "svn commit"
> >
>
> Great... if you always do your merges from your project root, you won't
> see this issue again.
>
> > How do we stop top posting and adhere to the rules ? We're new.
> >
>
> Just put your replys at the BOTTOM of your message, or inline as relevant,
> rather than at the top of your message.
>
> BOb
>
>
>
Hi Bob

Thanks again for responding.

We would take your suggestion.
Could you explain why this is happening to us "the unexpected touched
files" ?

Thanks

RE: merge using same revision number - quick question

[Bob Archer]

> On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer  wrote:
> > Hi Johan, Bob and all
> >
> > We took your suggestion and it still fails in that
> > 1- when we try to merge again at the root level
> > (goals:
> > a- to move subtree merge done previously to the working copy root
> > level so that the past merge can be traced at the root level using
> > "svn mergeinfo -show- revs merged)
> >
> > svn merge -c 498 https://test.com/svn/root /path/to/root
> >
> > But when we do a svn status, all other untouched files and folders
> > (unrelated to the revision number) are also touched.
> >
> > svn status -u
> > M           506 src/ap
> > M           506 src/ap/k.java
> > :
> > :
> >
> > We then commit.
> >
> > We performed the above steps for several other revision numbers and
> > still get the same svn status -u output for those files and folders
> > when executing those other subsequent revision numbers.
> >
> >
> > What are we doing wrong ?
> What are the changes to those files? I assume mergeinfo is being elided from
> all those files? If so, that is something that you want to happen. Once that 
> is
> done the first time, all your merge info will be in the root folder and you 
> won't
> see this any more.

> Thanks for your response.
> What does elided mean ?

Elide simple means remove.

> We do see the revision numbers are moved from eligible to merged in svn
> mergeinfo after a "svn merge" and "svn commit"
> 

Great... if you always do your merges from your project root, you won't see 
this issue again.

> How do we stop top posting and adhere to the rules ? We're new.
> 

Just put your replys at the BOTTOM of your message, or inline as relevant, 
rather than at the top of your message.

BOb

Re: merge using same revision number - quick question

[Z W]

Hi Bob

Thanks for your response.
What does elided mean ?
We do see the revision numbers are moved from eligible to merged in svn
mergeinfo after a "svn merge" and "svn commit"

How do we stop top posting and adhere to the rules ? We're new.

Thank you
Sincerely


On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer  wrote:

> > Hi Johan, Bob and all
> >
> > We took your suggestion and it still fails in that
> > 1- when we try to merge again at the root level
> > (goals:
> > a- to move subtree merge done previously to the working copy root level
> so
> > that the past merge can be traced at the root level using "svn mergeinfo
> -show-
> > revs merged)
> >
> > svn merge -c 498 https://test.com/svn/root /path/to/root
> >
> > But when we do a svn status, all other untouched files and
> folders (unrelated to
> > the revision number) are also touched.
> >
> > svn status -u
> > M   506 src/ap
> > M   506 src/ap/k.java
> > :
> > :
> >
> > We then commit.
> >
> > We performed the above steps for several other revision numbers and
> still get
> > the same svn status -u output for those files and folders when executing
> those
> > other subsequent revision numbers.
> >
> >
> > What are we doing wrong ?
>
> What are the changes to those files? I assume mergeinfo is being elided
> from all those files? If so, that is something that you want to happen.
> Once that is done the first time, all your merge info will be in the root
> folder and you won't see this any more.
>
>
> (Stop top posting!!!)
>
> >
> > Thanks all
> > sincerely
> >
> >
> >
> > On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer  wrote:
> > > Hi All
> > >
> > > We have a revision that contains a few changed files on the trunk:
> > > r345
> > > /usr/ext/a.java
> > > /usr/ext/b.java
> > >
> > > We like to merge this a branch working copy.
> > > Can we perform multiple merge svn with the same revision number ?
> > > We have a reason to do that; We know it doesnt make sense in this
> > > simple example.
> > >
> > > ie can we have 2 merge svn executions and still produce the same
> > > result as a simple merge execution.
> > > meaning
> > >
> > > svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java
> > > svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java
> > >
> > > as opposed to
> > > svn merge -c 345 https://test.com/svn/root/src/usr/ext
> > >
> > >
> > > Thanks all.
> > The resulting commit would probably be the same... although I expect the
> > merge info would be applied to the files rather than the folder. Give
> your
> > simple example a try in a test repo.
> >
> > BOb
>
>

RE: merge using same revision number - quick question

[Bob Archer]

> Hi Johan, Bob and all
> 
> We took your suggestion and it still fails in that
> 1- when we try to merge again at the root level
> (goals:
> a- to move subtree merge done previously to the working copy root level so
> that the past merge can be traced at the root level using "svn mergeinfo 
> -show-
> revs merged)
> 
> svn merge -c 498 https://test.com/svn/root /path/to/root
> 
> But when we do a svn status, all other untouched files and folders (unrelated 
> to
> the revision number) are also touched.
> 
> svn status -u
> M           506 src/ap
> M           506 src/ap/k.java
> :
> :
> 
> We then commit.
> 
> We performed the above steps for several other revision numbers and still get
> the same svn status -u output for those files and folders when executing those
> other subsequent revision numbers.
> 
> 
> What are we doing wrong ?

What are the changes to those files? I assume mergeinfo is being elided from 
all those files? If so, that is something that you want to happen. Once that is 
done the first time, all your merge info will be in the root folder and you 
won't see this any more.


(Stop top posting!!!)

> 
> Thanks all
> sincerely
> 
> 
> 
> On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer  wrote:
> > Hi All
> >
> > We have a revision that contains a few changed files on the trunk:
> > r345
> > /usr/ext/a.java
> > /usr/ext/b.java
> >
> > We like to merge this a branch working copy.
> > Can we perform multiple merge svn with the same revision number ?
> > We have a reason to do that; We know it doesnt make sense in this
> > simple example.
> >
> > ie can we have 2 merge svn executions and still produce the same
> > result as a simple merge execution.
> > meaning
> >
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java
> >
> > as opposed to
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext
> >
> >
> > Thanks all.
> The resulting commit would probably be the same... although I expect the
> merge info would be applied to the files rather than the folder. Give your
> simple example a try in a test repo.
> 
> BOb

Re: merge using same revision number - quick question

[Z W]

Hi Johan, Bob and all

We took your suggestion and it still fails in that
1- when we try to merge again at the root level
(goals:
a- to move subtree merge done previously to the working copy root level so
that the past merge can be traced at the root level using "svn mergeinfo
-show-revs merged)

svn merge -c 498
https://test.com/svn/root
 /path/to/root

But when we do a svn status, all other untouched files and
folders (unrelated to the revision number) are also touched.

svn status -u
M   506 src/ap
M   506 src/ap/k.java
:
:

We then commit.

We performed the above steps for several other revision numbers and still
get the same svn status -u output for those files and folders when
executing those other subsequent revision numbers.


What are we doing wrong ?

Thanks all
sincerely




On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer  wrote:

> > Hi All
> >
> > We have a revision that contains a few changed files on the trunk:
> > r345
> > /usr/ext/a.java
> > /usr/ext/b.java
> >
> > We like to merge this a branch working copy.
> > Can we perform multiple merge svn with the same revision number ?
> > We have a reason to do that; We know it doesnt make sense in this simple
> > example.
> >
> > ie can we have 2 merge svn executions and still produce the same result
> as a
> > simple merge execution.
> > meaning
> >
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java
> >
> > as opposed to
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext
> >
> >
> > Thanks all.
>
> The resulting commit would probably be the same... although I expect the
> merge info would be applied to the files rather than the folder. Give your
> simple example a try in a test repo.
>
> BOb
>
>

Re: merge using same revision number - quick question

[Johan Corveleyn]

On Mon, Apr 22, 2013 at 10:00 PM, Z W  wrote:
> Hi Johan
>
> Thanks for responding.

You're welcome :-). I'm putting the users list back in cc to keep it
in the loop. Please remember to use reply all for this reason.

> We didnt know of the subtree merging concept and you are right, we did
> perform some merges at the files level in the subdirectories.
>
> When you say
> "What might happen though is some elision (i.e. rearrangement) of
> mergeinfo: if you merge r345 at the root level, and it has previously
> been merged to all its operational targets with subtree merges (like
> in your example), SVN will remove the subtree mergeinfo, and just note
> that the entire r345 has been merged at the root level."
>
> In other words, if we now try to "re-merge" at the root level as you
> suggested, those previous subtree merges would not hurt, meaning messed up
> with double merges, right ?

No, it will not hurt. If everything works as advertised, this is a
perfectly supported use case (subtree merge tracking), and double
merges should not happen.

Feel free to double check by just trying it in a freshly checked out
working copy of your branch. You should be able to run the merge you
want to do, and then check what has happened by running 'svn diff'.

> We like to do it right this time the way you suggested.

Yes, establishing a policy of always merging at the "root level" (i.e.
avoiding subtree merges) makes things a lot simpler.

Another suggestion: previously in this thread you said you're using
SVN 1.6. I would highly recommend upgrading to 1.7 (at least for the
client(s) ...). The SVN client 1.7 has a lot of good improvements for
merge tracking. See:

http://subversion.apache.org/docs/release-notes/1.7.html#merge-tracking-enhancements

--
Johan

Re: merge using same revision number - quick question

[Johan Corveleyn]

[ Please don't top-post on this list, i.e. try to put your reply at
the bottom or inline. More below ... ]

On Sat, Apr 20, 2013 at 2:32 AM, Z W  wrote:
> On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer  wrote:
>>
>> > Hi All
>> >
>> > We have a revision that contains a few changed files on the trunk:
>> > r345
>> > /usr/ext/a.java
>> > /usr/ext/b.java
>> >
>> > We like to merge this a branch working copy.
>> > Can we perform multiple merge svn with the same revision number ?
>> > We have a reason to do that; We know it doesnt make sense in this simple
>> > example.
>> >
>> > ie can we have 2 merge svn executions and still produce the same result
>> > as a
>> > simple merge execution.
>> > meaning
>> >
>> > svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java
>> > svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java
>> >
>> > as opposed to
>> > svn merge -c 345 https://test.com/svn/root/src/usr/ext
>> >
>> >
>> > Thanks all.
>>
>> The resulting commit would probably be the same... although I expect the
>> merge info would be applied to the files rather than the folder. Give your
>> simple example a try in a test repo.
>>
>> BOb
>>
>
> Hi Bob
>
> Thanks for responding. I tried it and it seems to merge ok.
>
> We're usng SVN 1.6
> We tried using svn mergeinfo to help us with finding relevant revisions to
> merge from a trunk to a branch.
> But when we query for merged, (even for the one above),
> svn mergeinfo --shows-revs merged https://test.com/svn/root /path/to/root
> (executed but it returns nothing)
> But when we ran
> svn mergeinfo --shows-revs eligible https://test.com/svn/root /path/to/root
> (a list of revision numbers shows up including the r345).
> Why is that ?

That's because you didn't merge at the https://test.com/svn/root
level. You merged at https://test.com/svn/root/src/usr/ext or even
directly on the files beneath. That's called a "subtree merge".

When you ask subversion if r345 has been merged completely on
https://test.com/svn/root, it has to say "no" (i.e. on that level the
revision is still "eligible" for merging). Subversion doesn't know
that r345 has been merged on all individual subtrees or paths for
which r345 was operational (well, svn theoretically *could* know that,
but I think it would be expensive to find out).

That's why, for most regular use cases, it's highly recommended to
branch and merge always at the same "level" (usually at the "root" of
the branch). Subtree merging is supported, but it can be a bit more
difficult to understand and to handle in a large environment.

For example, if r345 affects both src/usr/ext/a.java and
src/usr/ext/b.java, and you only merge the revision on a.java, what
should SVN say when you ask whether r345 has been merged to ext? Is it
merged or is it still eligible? I'd say it's eligible, because parts
of it can still be merged (BTW: note that if you now merge r345 on
ext, SVN will correctly only merge the parts of b.java ... mergeinfo
will tell it that the revision has already been merged to a.java).

> Do you have a recommendation on
> 1- where to get the source of all rev numbers to merge from trunk to branch?
> Is svn log the only way where we have to parse the logs to get accurate
> count of revision numbers since mergeinfo fails us ?

Mergeinfo didn't fail you. As far as mergeinfo is concerned, you
didn't merge those revisions at the level you're asking.

If you standardize on always merging at the same level (and avoid
subtree merges), you'll not run into this problem.

> 2- if we apply merging command twice with the same arguments of trunk path
> directory and working copy path directory, will it hurt the branch ?

No. It's mergeinfo's job to keep track of what has been merged where.
If all goes well, it will not try to merge the same change twice.

What might happen though is some elision (i.e. rearrangement) of
mergeinfo: if you merge r345 at the root level, and it has previously
been merged to all its operational targets with subtree merges (like
in your example), SVN will remove the subtree mergeinfo, and just note
that the entire r345 has been merged at the root level.

For more information about merge tracking and mergeinfo, here are some
interesting blogs:

http://blogs.collab.net/subversion/subversion-15-1-2
http://blogs.collab.net/subversion/where-did-that-mergeinfo-come-from


--
Johan

Re: merge using same revision number - quick question

[Z W]

Hi Bob

Thanks for responding. I tried it and it seems to merge ok.

We're usng SVN 1.6
We tried using svn mergeinfo to help us with finding relevant revisions to
merge from a trunk to a branch.
But when we query for merged, (even for the one above),
svn mergeinfo --shows-revs merged
https://test.com/svn/root
 /path/to/root
(executed but it returns nothing)
But when we ran
svn mergeinfo --shows-revs eligible
https://test.com/svn/root
 /path/to/root
(a list of revision numbers shows up including the r345).
Why is that ?

Do you have a recommendation on
1- where to get the source of all rev numbers to merge from trunk to
branch? Is svn log the only way where we have to parse the logs to get
accurate count of revision numbers since mergeinfo fails us ?
2- if we apply merging command twice with the same arguments of trunk path
directory and working copy path directory, will it hurt the branch ?

Thansk


On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer  wrote:

> > Hi All
> >
> > We have a revision that contains a few changed files on the trunk:
> > r345
> > /usr/ext/a.java
> > /usr/ext/b.java
> >
> > We like to merge this a branch working copy.
> > Can we perform multiple merge svn with the same revision number ?
> > We have a reason to do that; We know it doesnt make sense in this simple
> > example.
> >
> > ie can we have 2 merge svn executions and still produce the same result
> as a
> > simple merge execution.
> > meaning
> >
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java
> >
> > as opposed to
> > svn merge -c 345 https://test.com/svn/root/src/usr/ext
> >
> >
> > Thanks all.
>
> The resulting commit would probably be the same... although I expect the
> merge info would be applied to the files rather than the folder. Give your
> simple example a try in a test repo.
>
> BOb
>
>

RE: merge using same revision number - quick question

[Bob Archer]

> Hi All
> 
> We have a revision that contains a few changed files on the trunk:
> r345
> /usr/ext/a.java
> /usr/ext/b.java
> 
> We like to merge this a branch working copy.
> Can we perform multiple merge svn with the same revision number ?
> We have a reason to do that; We know it doesnt make sense in this simple
> example.
> 
> ie can we have 2 merge svn executions and still produce the same result as a
> simple merge execution.
> meaning
> 
> svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java
> svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java
> 
> as opposed to
> svn merge -c 345 https://test.com/svn/root/src/usr/ext
> 
> 
> Thanks all.

The resulting commit would probably be the same... although I expect the merge 
info would be applied to the files rather than the folder. Give your simple 
example a try in a test repo.

BOb