[ 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 <mpc8250_at_gmail.com> wrote:
> On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer <Bob.Archer_at_amsi.com> 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
Received on 2013-04-22 21:17:52 CEST