You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jeremy Mordkoff <jl...@ZeeVee.Com> on 2010/03/31 22:01:27 UTC

subscribing

I'm having trouble subscribing. if there's a trick please let me know. I
sent mail to users-subscribe with just 'subscribe jlm@zeevee.com' in the
body.... no answer.


We use a lot of project branches,  that is, we branch from trunk,
develop a feature and then merge it back to trunk. Quite often, we need
to merge a change or two from trunk out to our branch along the way.
What I have noticed is that when I go to merge the branch back to trunk,
the changes that were merged from trunk to the branch are included when
I do a 'svn mergeinfo --show-revs eligible <branchname> <trunk>'. Why is
this? Shouldn't the system know that these were merged out and therefore
do not need to be merged in? I do not ever use 'ignore-ancestry'. 

I end up doing a lot of 'svn merge --record-only's to block the reverse
merges.

Please reply directly as I do not seem to be able to subscribe.

Thanks,
JLM

Re: subscribing

Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/4/1 Bob Archer <Bo...@amsi.com>:
>> I'm having trouble subscribing. if there's a trick please let me know. I
>> sent mail to users-subscribe with just 'subscribe jlm@zeevee.com' in the
>> body.... no answer.
>
> You are sending an email to users-subscribe@subversion.apache.org ? No subject no body?
>

See note about spam filters here:
http://www.apache.org/foundation/mailinglists.html

Best regards,
Konstantin Kolinko

RE: mergeinfo and reintegrate

Posted by Bob Archer <Bo...@amsi.com>.
> Svn help mergeinfo does not reference --reintegrate at all. Are you
> saying that a merge with the
> -reintegrate option may skip some items that mergeinfo lists as
> eligible?

Certainly it does.

When you do...

~/MyProjectsTrunk/ $ svn merge ^/branch/MyFeature

svn will look at the trunk and find all merge info to see what revs from branch have already been brought in. Lets say it's none... so it will do a diff from the rev where your branch started to HEAD and apply that diff to trunk.

However, if you do a:

~/MyProjectsTrunk/ $ svn merge --reintegreate ^/branch/MyFeature 

svn will do a 2-URL merge doing a diff between trunk@HEAD and MyFeature@HEAD (I am pretty sure see http://blogs.open.collab.net/svn/2008/07/subversion-merg.html for a full explaination).

So, when you do a mergeinfo it is assuming you are doing a single URL merge, the first command above.

At least, as far as I understand it that is what is going on. 

> Also the help for reintegrate says that the only difference is that it
> treats the merge as a lump sum, not as a sequence of mini merges. Are

Right... because when you do svn merge ^/trunk in your branch for example, it is bringing in each revision from trunk that hasn't been merged yet. But, when you do a reintegrate from a branch to trunk it is doing a 2-URL merge which basically diffs the head of trunk with the head of branch and applies it to trunk. (This is the same thing you would have done manually prior to svn 1.5.)


> you saying that if you have done a complete merge out, you can skip the
> individual merge ins and just do one big reintegrate? If so, Is doing a
> complete merge out first mandatory? (I would think so). Can this model
> handle files that were deleted and re-added?

Sort answer is YES. Long answer is: If you have a feature branch... and you merge from trunk, in order to merge the changes made in the branch that you want to apply to trunk you do the reintegrate. As I said above since this is a 2-URL merge you must have all of trunk merged into the feature branch. (BTW: This is just the use case for a feature branch. You would do it differently if you were doing perhaps a release branch.)


> Actually, now that I have written and reread this, I think I answered my
> own question. Using reintegrate is orthogonal to using mergeinfo. You
> use mergeinfo to pick up changes that have been made in a release branch
> that need to be merged to trunk, and you use -reintegrate to merge a
> project branch back to its baseline.
> 
> I feel like I must have missed that section in the book. Is this not
> documented?

It is documented... but reading the blog entry I linked to above gives you a lot more information.

BOb

mergeinfo and reintegrate

Posted by Jeremy Mordkoff <jl...@ZeeVee.Com>.
> > We use a lot of project branches,  that is, we branch from trunk,
> > develop a feature and then merge it back to trunk. Quite often, we
need
> > to merge a change or two from trunk out to our branch along the way.
> > What I have noticed is that when I go to merge the branch back to
trunk,
> > the changes that were merged from trunk to the branch are included
when
> > I do a 'svn mergeinfo --show-revs eligible <branchname> <trunk>'.
Why is
> > this? Shouldn't the system know that these were merged out and
therefore
> > do not need to be merged in? I do not ever use 'ignore-ancestry'.
> >
> > I end up doing a lot of 'svn merge --record-only's to block the
reverse
> > merges.
> 
> If you have a feature branch you should be merging from trunk into the
branch regularly. then
> when you are done with the feature you would do a reintegrate merge
back. I don't see an
> argument on merginfo to specify that you want to do a re-integrate.
> 

Svn help mergeinfo does not reference --reintegrate at all. Are you
saying that a merge with the 
-reintegrate option may skip some items that mergeinfo lists as
eligible? 

Also the help for reintegrate says that the only difference is that it
treats the merge as a lump sum, not as a sequence of mini merges. Are
you saying that if you have done a complete merge out, you can skip the
individual merge ins and just do one big reintegrate? If so, Is doing a
complete merge out first mandatory? (I would think so). Can this model
handle files that were deleted and re-added? 

Actually, now that I have written and reread this, I think I answered my
own question. Using reintegrate is orthogonal to using mergeinfo. You
use mergeinfo to pick up changes that have been made in a release branch
that need to be merged to trunk, and you use -reintegrate to merge a
project branch back to its baseline.

I feel like I must have missed that section in the book. Is this not
documented? 

Thanks
JLM

RE: subscribing

Posted by Bob Archer <Bo...@amsi.com>.
> I'm having trouble subscribing. if there's a trick please let me know. I
> sent mail to users-subscribe with just 'subscribe jlm@zeevee.com' in the
> body.... no answer.

You are sending an email to users-subscribe@subversion.apache.org ? No subject no body?

> We use a lot of project branches,  that is, we branch from trunk,
> develop a feature and then merge it back to trunk. Quite often, we need
> to merge a change or two from trunk out to our branch along the way.
> What I have noticed is that when I go to merge the branch back to trunk,
> the changes that were merged from trunk to the branch are included when
> I do a 'svn mergeinfo --show-revs eligible <branchname> <trunk>'. Why is
> this? Shouldn't the system know that these were merged out and therefore
> do not need to be merged in? I do not ever use 'ignore-ancestry'.
> 
> I end up doing a lot of 'svn merge --record-only's to block the reverse
> merges.

If you have a feature branch you should be merging from trunk into the branch regularly. then when you are done with the feature you would do a reintegrate merge back. I don't see an argument on merginfo to specify that you want to do a re-integrate.

BOb