You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Colm Aengus Murphy <co...@s3group.com> on 2008/07/07 10:44:24 UTC
Problem with merge tracking in 1.5.0
Hi folks,
I'm seeing a problem with the merge tracking feature in 1.5.0 and was
wondering if anyone else has seen this.
The problem occurs when doing a repeated merge of a user branch back to
a development branch.
I ran two tests.
In the first test a file was edited in both devel and user branches but
the edits were in different parts of the file.
When the user branch was merged using "svn merge --reintegrate" svn did
an automatic merge. I commit the changes.
If the merge command is repeated at a later stage svn notices that the
merge already took place and doesn't merge the file.
(it does however update the top level directory with the details of the
merge even though no merge was necessary which is a separate issue)
In the second test the file was edited in both devel and user branches
but this time in the same part of the file.
When the user branch was merged using "svn merge --reintegrate" svn
flags a conflict. I manually resolve the conflict and commit the changes.
This time if the merge command is repeated at a later stage svn doesn't
seem to notice that the merge already took place and flags a conflict.
Is this a bug ?
I'm using svn 1.5.0 on RHEL4 (the same problem is also seen using svn
1.5.0 on win32)
Regards
Colm A
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by Colm Aengus Murphy <co...@s3group.com>.
#!/bin/csh
set pwd = `pwd`
set REPO = $pwd/repo
set WORK = $pwd/work
mkdir $WORK
echo "Creating repo structure"
svnadmin create $REPO
svn mkdir -m "Created branches" file://$REPO/branches
svn mkdir -m "Created devel branch" file://$REPO/branches/devel
svn mkdir -m "Created devel/tools" file://$REPO/branches/devel/tools
echo "Checkout devel and add file"
cd $WORK
svn checkout file://$REPO/branches/devel/tools tools
echo "This is a file" > tools/file.txt
svn add tools/file.txt
svn commit -m "Initial commit" tools
svn update tools
echo "Create private branch"
# Create a private branch
svn mkdir -m "Created private_1 branch" file://$REPO/branches/private_1
svn copy -m "copied to private_1 branch" file://$REPO/branches/devel/tools file://$REPO/branches/private_1
echo "Switch to private branch and make an change"
svn switch file://$REPO/branches/private_1/tools tools
echo "change made on private_1" >> tools/file.txt
svn commit -m "change made on private_1" tools
svn update tools
echo "Switch to devel branch and make an conflicting change"
svn switch file://$REPO/branches/devel/tools tools
echo "change made on devel" >> tools/file.txt
svn commit -m "change made on devel" tools
svn update tools
echo "Merge to devel"
svn merge --reintegrate --accept postpone file://$REPO/branches/private_1/tools tools
echo "Resolve conflict and commit"
echo "This is a file" > tools/file.txt
echo "resolved changes" >> tools/file.txt
svn resolve --accept working tools/file.txt
svn commit -m "Merged changes from private_1" tools
svn update tools
svn log -g tools
echo "Try to repeat the merge to devel"
svn merge --reintegrate --accept postpone file://$REPO/branches/private_1/tools tools
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
Re: Problem with merge tracking in 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jul 16, 2008 at 5:57 AM, Colm Aengus Murphy
<co...@s3group.com> wrote:
> Thanks for the info. It might be worth to update the red-bean doc in the
> section where it describes that you can continually perform reintegration
> merges.
>
> "Now that your branch is merged to trunk, you have a couple of options. You
> can keep working on your branch, repeating the whole process of occasionally
> syncing with the trunk and eventually using --reintegrate to merge it back
> again. Or, if you're really done with the branch, you can destroy your
> working copy of it and then remove it from the repository."
I will send an email to the authors.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by Colm Aengus Murphy <co...@s3group.com>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Mark,<br>
<br>
Thanks for the info. It might be worth to update the red-bean doc in
the section where it describes that you can continually perform
reintegration merges.<br>
<br>
"Now that your branch is merged to trunk, you have a couple of options.
You can keep working on your branch, repeating the whole process of
occasionally syncing with the trunk and eventually using <code
class="option">--reintegrate</code> to merge it back again. Or, if
you're really done with the branch, you can destroy your working copy
of it and then remove it from the repository."<br>
<br>
Regards<br>
<br>
Colm A<br>
<br>
Mark Phippard wrote:
<blockquote
cite="mid:ff892c5d0807130929kf233eau55f0c607433e6f56@mail.gmail.com"
type="cite">
<pre wrap="">Colm,
I finally got that blog post published.
<a class="moz-txt-link-freetext" href="http://blogs.open.collab.net/svn/2008/07/subversion-merg.html">http://blogs.open.collab.net/svn/2008/07/subversion-merg.html</a>
It explains some of the issues with merge and reintegrate. Your issue
is covered near the end under the Branch Management section. In your
reproduction, Subversion is behaving as expected. You would probably
want to handle this situation by deleting branches after they are
reintegrated and then create them again if necessary.
Thanks
Mark
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
---------------------------------------------------------------------
Colm Aengus Murphy, Tel : +353 1 2911000
Release Manager, Direct Tel: +353 1 2911373
Consumer Mobile,
Silicon & Software Systems, Fax : +353 1 2911001
South County Business Park,
Leopardstown, E-mail: <a class="moz-txt-link-abbreviated" href="mailto:colm.murphy@s3group.com">colm.murphy@s3group.com</a>
Dublin 18. WWW : <a class="moz-txt-link-abbreviated" href="http://www.s3group.com">www.s3group.com</a>
Ireland
---------------------------------------------------------------------
</pre>
<H6><BR><HR>
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
<BR><HR><BR></H6></body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by J J <eg...@gmail.com>.
On Fri, Jul 18, 2008 at 11:13 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Jul 18, 2008 at 12:07 PM, J J <eg...@gmail.com> wrote:
>
> >> It is fine to merge on sub-directories or files. What is not fine, is
> >> to try to mix that with whole branch merges. The theory behind
> >> reintegrate was that users were likely to do one or the other. The
> >> big wrench stuck in the spokes of that idea was move/rename creating
> >> this information.
> >
> > Making subtree merges and whole branches merges mutually exclusive is a
> > pretty big assumption. Is that explicitly stated anywhere so users know
> > what they're getting into? As far as releasing incremental merge
> tracking
> > functionality it is definitely a step forward, but hopefully not the end
> > goal.
>
> I did not mean to imply they are mutually exclusive or intended to be
> that way. It really gets back to this one problem of reflective
> merges and the "solution" we put in place for 1.5. The reintegrate
> option is a purely whole branch solution. But for example something
> that works really well in 1.5 is to cherry pick a few files or
> revisions to a branch and then later go back and merge everything to
> that branch.
I agree. Cherry picking and full branch merging work great when reintegrate
is not involved. Reintegrate is needed by many teams though. I just wanted
to make sure it was clear to new users.
I'm getting a better handle on the issues so I'll put the appropriate
processes in place for our company to avoid them until they are fixed
(hopefully) in future releases.
Thanks,
Justin
Re: Problem with merge tracking in 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jul 18, 2008 at 12:07 PM, J J <eg...@gmail.com> wrote:
>> It is fine to merge on sub-directories or files. What is not fine, is
>> to try to mix that with whole branch merges. The theory behind
>> reintegrate was that users were likely to do one or the other. The
>> big wrench stuck in the spokes of that idea was move/rename creating
>> this information.
>
> Making subtree merges and whole branches merges mutually exclusive is a
> pretty big assumption. Is that explicitly stated anywhere so users know
> what they're getting into? As far as releasing incremental merge tracking
> functionality it is definitely a step forward, but hopefully not the end
> goal.
I did not mean to imply they are mutually exclusive or intended to be
that way. It really gets back to this one problem of reflective
merges and the "solution" we put in place for 1.5. The reintegrate
option is a purely whole branch solution. But for example something
that works really well in 1.5 is to cherry pick a few files or
revisions to a branch and then later go back and merge everything to
that branch.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by J J <eg...@gmail.com>.
On Fri, Jul 18, 2008 at 10:38 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Jul 18, 2008 at 10:47 AM, J J <eg...@gmail.com> wrote:
>
> > I have noticed that doing a complete merge repeatedly from trunk to the
> > branch doesn't elide away subtree mergeinfo unless you do an update first
> on
> > the branch working copy first. A test case (test2.sh) is attached. Can
> you
> > explain why?
>
> Have you read Paul Burba's mergeinfo "manifesto"? It might offer some
> clues. It is linked from this blog:
>
> http://blogs.open.collab.net/svn/2008/05/subversion-15-1.html
>
>
Wow, that's a lot of info! I'll take a look. Thanks.
>
> > I see. I got confused because the 1.5 client still adds empty mergeinfo
> in
> > some cases, even though the repository isn't upgraded. Subsequent merge
> > attempts remove that mergeinfo though, which I didn't notice before.
> > Everything is working as expected after the upgrade.
>
> A local svn move adds empty mergeinfo. It does not so that it can
> avoid contacting the repository during the merge, but leave behind a
> marker for the commit process to decide what to do. I'd think that
> commit would see the server does not support mergeinfo and remove the
> property or something. Not really sure though.
>
> > Okay. So the issue is that the 2-URL merge can't account for the fact
> that
> > parts of revisions have already been merged to the branch that will be
> > reintegrated back to trunk, and thus the diff is not what the user would
> > expect. Right?
>
> Yes. Basically, 2-URL merge is just going to diff what you tell it.
> It is not hard to imagine scenarios where that is not the result you
> really want. The reintegrate option tries to recognize these
> situations and stop you.
>
>
> > I see that if after performing a reintegrate from branch to trunk I then
> do
> > an empty merge from trunk back to branch, then reintegrating from branch
> to
> > trunk works because it uses the new revision. (See attached test1.sh to
> > reproduce this) This doesn't seem very intutive to me, but at least I'm
> > getting a better handle on how merge tracking actually works. Has anyone
> > been bouncing around ideas for improving this (i.e. for updating the
> > revision to use after merging everything from the branch back to trunk)?
>
> Not really. There isn't any mechanism to update the branch, so I do
> not see a lot of opportunity to resolve it.
>
> > This makes sense as long as users understand they really shouldn't be
> > merging on sub directories or files, even though the tool lets them.
> > Assuming they understand this, the only confusing part then would be the
> > creation of subtree mergeinfo on copy/move/rename, thus preventing
> > reintegrate from happening. I don't entirely understand what will be
> > included in 1.5.1, but hopefully there will be a fix for this.
>
> It is fine to merge on sub-directories or files. What is not fine, is
> to try to mix that with whole branch merges. The theory behind
> reintegrate was that users were likely to do one or the other. The
> big wrench stuck in the spokes of that idea was move/rename creating
> this information.
>
Making subtree merges and whole branches merges mutually exclusive is a
pretty big assumption. Is that explicitly stated anywhere so users know
what they're getting into? As far as releasing incremental merge tracking
functionality it is definitely a step forward, but hopefully not the end
goal.
> > Ah, I see! The light has been turned on! Can you provide any info on
> > how/if this will be smarter in 1.5.1?
>
> It does not look like it will make it into 1.5.1, which is being cut
> next week. The idea behind the fix would be that if the parent
> containing mergeinfo is the same before and after the merge, then
> there is no need to create mergeinfo.
>
Okay, that makes sense.
Re: Problem with merge tracking in 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jul 18, 2008 at 10:47 AM, J J <eg...@gmail.com> wrote:
> I have noticed that doing a complete merge repeatedly from trunk to the
> branch doesn't elide away subtree mergeinfo unless you do an update first on
> the branch working copy first. A test case (test2.sh) is attached. Can you
> explain why?
Have you read Paul Burba's mergeinfo "manifesto"? It might offer some
clues. It is linked from this blog:
http://blogs.open.collab.net/svn/2008/05/subversion-15-1.html
> I see. I got confused because the 1.5 client still adds empty mergeinfo in
> some cases, even though the repository isn't upgraded. Subsequent merge
> attempts remove that mergeinfo though, which I didn't notice before.
> Everything is working as expected after the upgrade.
A local svn move adds empty mergeinfo. It does not so that it can
avoid contacting the repository during the merge, but leave behind a
marker for the commit process to decide what to do. I'd think that
commit would see the server does not support mergeinfo and remove the
property or something. Not really sure though.
> Okay. So the issue is that the 2-URL merge can't account for the fact that
> parts of revisions have already been merged to the branch that will be
> reintegrated back to trunk, and thus the diff is not what the user would
> expect. Right?
Yes. Basically, 2-URL merge is just going to diff what you tell it.
It is not hard to imagine scenarios where that is not the result you
really want. The reintegrate option tries to recognize these
situations and stop you.
> I see that if after performing a reintegrate from branch to trunk I then do
> an empty merge from trunk back to branch, then reintegrating from branch to
> trunk works because it uses the new revision. (See attached test1.sh to
> reproduce this) This doesn't seem very intutive to me, but at least I'm
> getting a better handle on how merge tracking actually works. Has anyone
> been bouncing around ideas for improving this (i.e. for updating the
> revision to use after merging everything from the branch back to trunk)?
Not really. There isn't any mechanism to update the branch, so I do
not see a lot of opportunity to resolve it.
> This makes sense as long as users understand they really shouldn't be
> merging on sub directories or files, even though the tool lets them.
> Assuming they understand this, the only confusing part then would be the
> creation of subtree mergeinfo on copy/move/rename, thus preventing
> reintegrate from happening. I don't entirely understand what will be
> included in 1.5.1, but hopefully there will be a fix for this.
It is fine to merge on sub-directories or files. What is not fine, is
to try to mix that with whole branch merges. The theory behind
reintegrate was that users were likely to do one or the other. The
big wrench stuck in the spokes of that idea was move/rename creating
this information.
> Ah, I see! The light has been turned on! Can you provide any info on
> how/if this will be smarter in 1.5.1?
It does not look like it will make it into 1.5.1, which is being cut
next week. The idea behind the fix would be that if the parent
containing mergeinfo is the same before and after the merge, then
there is no need to create mergeinfo.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by J J <eg...@gmail.com>.
On Wed, Jul 16, 2008 at 1:01 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Jul 16, 2008 at 1:08 PM, J J <eg...@gmail.com> wrote:
>
> > Thanks for the excellent post. Would you mind confirming my current
> > understanding of how merge tracking works, and then answering some
> remaining
> > questions I have? I would have posted to the collabnet forum, but the
> list
> > seemed like a better place to have this information recorded.
> >
> > My Understanding
> > ----------------
> > 1) A merge will update the mergeinfo even if no merge was done, to
> increment
> > the merged revision (i.e. even if the revisions weren't on source branch
> > they are recorded in the mergeinfo).
>
> Correct. This is something we are frequently discussing though, and
> it could change.
>
> > 2) After performing a merge, you can perform another merge before
> checking
> > in the first merge results (except when using --reintegrate).
>
> Yes. Which is of course good and bad.
>
> > 3) If you run "svn merge url:/repo/trunk/foo.c", mergeinfo is stored in
> > foo.c
>
> Stored in the svn:mergeinfo property on foo.c. Yes.
>
> > 4) Merges performed at the top of the branch remove superfluous mergeinfo
> > from sub-directories / files since the entire revision is recorded in the
> > mergeinfo stored on the branch.
>
> Yes. This is called elision. If all of the subtree mergeinfo is now
> accounted for at a parent level, the mergeinfo should "elide" away to
> the parent. NOTE: If we were to change your question #1 it would
> remove, or at least limit, the ability to do this.
I have noticed that doing a complete merge repeatedly from trunk to the
branch doesn't elide away subtree mergeinfo unless you do an update first on
the branch working copy first. A test case (test2.sh) is attached. Can you
explain why?
> > 5) Before you can use --reintegrate, the repository must be upgraded with
> > "svnadmin upgrade /paht/to/repo". Otherwise you will receive the
> following
> > error:
> >
> > svn: Retrieval of mergeinfo unsupported by 'url://repo'
>
> Yes. But this is also needed for all of the previous as well. If
> your repository is not at 1.5, merge tracking information is not
> created.
>
I see. I got confused because the 1.5 client still adds empty mergeinfo in
some cases, even though the repository isn't upgraded. Subsequent merge
attempts remove that mergeinfo though, which I didn't notice before.
Everything is working as expected after the upgrade.
>
> > My Questions
> > ------------
> > 1) In the blog post you mention that a 2-URL merge for branches with
> subtree
> > mergeinfo doesn't always give the correct results. I don't yet
> understand
> > why this is the case. Would you mind explaining why in more detail? Is
> > this true only when the subtree mergeinfo is on the source branch or also
> > when it is on the destination branch?
>
> Well, it gives the "correct" results, it might not give the expected
> results. Consider a revision that changes folder1/foo.c and
> folder2/bar.c. In your branch you merged the changes to folder1 and
> not folder2. If you later do a 2-URL merge, it will look like you
> removed the changes in folder2 and so those changes will now be
> removed from trunk. That probably would not be what you expected.
Okay. So the issue is that the 2-URL merge can't account for the fact that
parts of revisions have already been merged to the branch that will be
reintegrated back to trunk, and thus the diff is not what the user would
expect. Right?
> > 2) You mentioned that reintegrate can't be performed more than once from
> the
> > same branch. I'm trying to understand what exactly the issue is. Here
> is
> > what I did and the results I got.
> >
> > On branch a add line to foo.c and commit.
> > Merge with --reintegrate from branch a to trunk and commit.
> > On trunk remove same added line from foo.c and commit.
> > Merge again with --reintegrate from a and to trunk.
> > The line was added back to foo.c, whereas I would have hoped reintegrate
> was
> > smart enough to know I already reintegrated that change from branch a.
> See
> > attached script to reproduce this.
> >
> > Can you explain why this happened (assuming you answer to 1 doesn't
> explain
> > this)?
>
> Remember that reintegrate is a short cut to a 2-URL merge, which is
> essentially a fancy diff and apply operation. Reintegrate figures out
> one of URL@REV pairs for you. It basically looks for the last REV
> that was merged to the branch. In your example, this REV does not
> change, so each merge does the exact same thing each time. What you
> would need is something in between these steps to advance the REV on
> the branch.
I see that if after performing a reintegrate from branch to trunk I then do
an empty merge from trunk back to branch, then reintegrating from branch to
trunk works because it uses the new revision. (See attached test1.sh to
reproduce this) This doesn't seem very intutive to me, but at least I'm
getting a better handle on how merge tracking actually works. Has anyone
been bouncing around ideas for improving this (i.e. for updating the
revision to use after merging everything from the branch back to trunk)?
> > 3) As you mentioned, there are additional checks performed when using
> > --reintegrate (mixed revisions, no local mods, ancestry, subtree
> > mergeinfo). Besides the subtree mergeinfo check, can you explain why
> these
> > checks are needed with reintegrate and not in the case of normal merges?
>
> They are "best practices" and I think it was a matter of some people
> wishing that normal merges did do those checks. In the CollabNet
> Merge client, we allow you to run those checks as part of any merge.
> In the case of reintegrate, it is also because the merge is
> essentially a diff + apply and the command is founded upon the idea
> that you only branch and merge at the entire branch level. If you
> start changing that promise you now remove yourself as a candidate for
> using this option. So it is just trying to enforce that and keep
> things clean.
>
This makes sense as long as users understand they really shouldn't be
merging on sub directories or files, even though the tool lets them.
Assuming they understand this, the only confusing part then would be the
creation of subtree mergeinfo on copy/move/rename, thus preventing
reintegrate from happening. I don't entirely understand what will be
included in 1.5.1, but hopefully there will be a fix for this.
>
> > 4) In your post you say "why copy/move create mergeinfo are beyond the
> scope
> > of this post". Would you mind clarifying here? I'm sure the light bulb
> > will turn on for me with a little more explanation. :-)
>
> Picture you have two folders, folder1 and folder2. folder1 has
> explicit mergeinfo and folder2 does not. If you move something from
> folder2 to folder1, it needs to create explicit mergeinfo on the item
> you moved, so that Subversion knows that the file has a different set
> of revisions then its parent folder. If the parent with mergeinfo is
> the same before and after the move, which would be typical in the
> normal cases, there really is no good reason to create explicit
> mergeinfo. This is the sort of optimization that needs to be made.
Ah, I see! The light has been turned on! Can you provide any info on
how/if this will be smarter in 1.5.1?
Thanks so much for your explanations.
Justin
Re: Problem with merge tracking in 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jul 16, 2008 at 1:08 PM, J J <eg...@gmail.com> wrote:
> Thanks for the excellent post. Would you mind confirming my current
> understanding of how merge tracking works, and then answering some remaining
> questions I have? I would have posted to the collabnet forum, but the list
> seemed like a better place to have this information recorded.
>
> My Understanding
> ----------------
> 1) A merge will update the mergeinfo even if no merge was done, to increment
> the merged revision (i.e. even if the revisions weren't on source branch
> they are recorded in the mergeinfo).
Correct. This is something we are frequently discussing though, and
it could change.
> 2) After performing a merge, you can perform another merge before checking
> in the first merge results (except when using --reintegrate).
Yes. Which is of course good and bad.
> 3) If you run "svn merge url:/repo/trunk/foo.c", mergeinfo is stored in
> foo.c
Stored in the svn:mergeinfo property on foo.c. Yes.
> 4) Merges performed at the top of the branch remove superfluous mergeinfo
> from sub-directories / files since the entire revision is recorded in the
> mergeinfo stored on the branch.
Yes. This is called elision. If all of the subtree mergeinfo is now
accounted for at a parent level, the mergeinfo should "elide" away to
the parent. NOTE: If we were to change your question #1 it would
remove, or at least limit, the ability to do this.
> 5) Before you can use --reintegrate, the repository must be upgraded with
> "svnadmin upgrade /paht/to/repo". Otherwise you will receive the following
> error:
>
> svn: Retrieval of mergeinfo unsupported by 'url://repo'
Yes. But this is also needed for all of the previous as well. If
your repository is not at 1.5, merge tracking information is not
created.
> My Questions
> ------------
> 1) In the blog post you mention that a 2-URL merge for branches with subtree
> mergeinfo doesn't always give the correct results. I don't yet understand
> why this is the case. Would you mind explaining why in more detail? Is
> this true only when the subtree mergeinfo is on the source branch or also
> when it is on the destination branch?
Well, it gives the "correct" results, it might not give the expected
results. Consider a revision that changes folder1/foo.c and
folder2/bar.c. In your branch you merged the changes to folder1 and
not folder2. If you later do a 2-URL merge, it will look like you
removed the changes in folder2 and so those changes will now be
removed from trunk. That probably would not be what you expected.
> 2) You mentioned that reintegrate can't be performed more than once from the
> same branch. I'm trying to understand what exactly the issue is. Here is
> what I did and the results I got.
>
> On branch a add line to foo.c and commit.
> Merge with --reintegrate from branch a to trunk and commit.
> On trunk remove same added line from foo.c and commit.
> Merge again with --reintegrate from a and to trunk.
> The line was added back to foo.c, whereas I would have hoped reintegrate was
> smart enough to know I already reintegrated that change from branch a. See
> attached script to reproduce this.
>
> Can you explain why this happened (assuming you answer to 1 doesn't explain
> this)?
Remember that reintegrate is a short cut to a 2-URL merge, which is
essentially a fancy diff and apply operation. Reintegrate figures out
one of URL@REV pairs for you. It basically looks for the last REV
that was merged to the branch. In your example, this REV does not
change, so each merge does the exact same thing each time. What you
would need is something in between these steps to advance the REV on
the branch.
> 3) As you mentioned, there are additional checks performed when using
> --reintegrate (mixed revisions, no local mods, ancestry, subtree
> mergeinfo). Besides the subtree mergeinfo check, can you explain why these
> checks are needed with reintegrate and not in the case of normal merges?
They are "best practices" and I think it was a matter of some people
wishing that normal merges did do those checks. In the CollabNet
Merge client, we allow you to run those checks as part of any merge.
In the case of reintegrate, it is also because the merge is
essentially a diff + apply and the command is founded upon the idea
that you only branch and merge at the entire branch level. If you
start changing that promise you now remove yourself as a candidate for
using this option. So it is just trying to enforce that and keep
things clean.
> 4) In your post you say "why copy/move create mergeinfo are beyond the scope
> of this post". Would you mind clarifying here? I'm sure the light bulb
> will turn on for me with a little more explanation. :-)
Picture you have two folders, folder1 and folder2. folder1 has
explicit mergeinfo and folder2 does not. If you move something from
folder2 to folder1, it needs to create explicit mergeinfo on the item
you moved, so that Subversion knows that the file has a different set
of revisions then its parent folder. If the parent with mergeinfo is
the same before and after the move, which would be typical in the
normal cases, there really is no good reason to create explicit
mergeinfo. This is the sort of optimization that needs to be made.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by J J <eg...@gmail.com>.
> I finally got that blog post published.
>
> http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
>
> It explains some of the issues with merge and reintegrate. Your issue
> is covered near the end under the Branch Management section. In your
> reproduction, Subversion is behaving as expected. You would probably
> want to handle this situation by deleting branches after they are
> reintegrated and then create them again if necessary.
Mark,
Thanks for the excellent post. Would you mind confirming my current
understanding of how merge tracking works, and then answering some remaining
questions I have? I would have posted to the collabnet forum, but the list
seemed like a better place to have this information recorded.
My Understanding
----------------
1) A merge will update the mergeinfo even if no merge was done, to increment
the merged revision (i.e. even if the revisions weren't on source branch
they are recorded in the mergeinfo).
2) After performing a merge, you can perform another merge before checking
in the first merge results (except when using --reintegrate).
3) If you run "svn merge url:/repo/trunk/foo.c", mergeinfo is stored in
foo.c
4) Merges performed at the top of the branch remove superfluous mergeinfo
from sub-directories / files
since the entire revision is recorded in the mergeinfo stored on the
branch.
5) Before you can use --reintegrate, the repository must be upgraded with
"svnadmin upgrade /paht/to/repo". Otherwise you will receive the following
error:
svn: Retrieval of mergeinfo unsupported by 'url://repo'
My Questions
------------
1) In the blog post you mention that a 2-URL merge for branches with subtree
mergeinfo doesn't always give the correct results. I don't yet understand
why this is the case. Would you mind explaining why in more detail? Is
this true only when the subtree mergeinfo is on the source branch or also
when it is on the destination branch?
2) You mentioned that reintegrate can't be performed more than once from the
same branch. I'm trying to understand what exactly the issue is. Here is
what I did and the results I got.
On branch a add line to foo.c and commit.
Merge with --reintegrate from branch a to trunk and commit.
On trunk remove same added line from foo.c and commit.
Merge again with --reintegrate from a and to trunk.
The line was added back to foo.c, whereas I would have hoped reintegrate was
smart enough to know I already reintegrated that change from branch a. See
attached script to reproduce this.
Can you explain why this happened (assuming you answer to 1 doesn't explain
this)?
3) As you mentioned, there are additional checks performed when using
--reintegrate (mixed revisions, no local mods, ancestry, subtree
mergeinfo). Besides the subtree mergeinfo check, can you explain why these
checks are needed with reintegrate and not in the case of normal merges?
4) In your post you say "why copy/move create mergeinfo are beyond the scope
of this post". Would you mind clarifying here? I'm sure the light bulb
will turn on for me with a little more explanation. :-)
Thanks,
Justin
Re: Problem with merge tracking in 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
Colm,
I finally got that blog post published.
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
It explains some of the issues with merge and reintegrate. Your issue
is covered near the end under the Branch Management section. In your
reproduction, Subversion is behaving as expected. You would probably
want to handle this situation by deleting branches after they are
reintegrated and then create them again if necessary.
Thanks
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by Colm Aengus Murphy <co...@s3group.com>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Mark,<br>
<br>
Here is a script you can use to reproduce the problem.<br>
<br>
Regards<br>
<br>
Colm A<br>
<br>
#!/bin/csh<br>
<br>
set pwd = `pwd`<br>
set REPO = $pwd/repo<br>
set WORK = $pwd/work<br>
<br>
mkdir $WORK<br>
<br>
echo "Creating repo structure"<br>
svnadmin create $REPO<br>
svn mkdir -m "Created branches" <a class="moz-txt-link-freetext" href="file://$REPO/branches">file://$REPO/branches</a><br>
svn mkdir -m "Created devel branch" <a class="moz-txt-link-freetext" href="file://$REPO/branches/devel">file://$REPO/branches/devel</a><br>
svn mkdir -m "Created devel/tools" <a class="moz-txt-link-freetext" href="file://$REPO/branches/devel/tools">file://$REPO/branches/devel/tools</a><br>
<br>
echo "Checkout devel and add file"<br>
cd $WORK<br>
svn checkout <a class="moz-txt-link-freetext" href="file://$REPO/branches/devel/tools">file://$REPO/branches/devel/tools</a> tools<br>
echo "This is a file" > tools/file.txt<br>
svn add tools/file.txt<br>
svn commit -m "Initial commit" tools<br>
svn update tools<br>
<br>
echo "Create private branch"<br>
<br>
# Create a private branch<br>
svn mkdir -m "Created private_1 branch" <a class="moz-txt-link-freetext" href="file://$REPO/branches/private_1">file://$REPO/branches/private_1</a><br>
svn copy -m "copied to private_1 branch"
<a class="moz-txt-link-freetext" href="file://$REPO/branches/devel/tools">file://$REPO/branches/devel/tools</a> <a class="moz-txt-link-freetext" href="file://$REPO/branches/private_1">file://$REPO/branches/private_1</a><br>
<br>
echo "Switch to private branch and make an change"<br>
svn switch <a class="moz-txt-link-freetext" href="file://$REPO/branches/private_1/tools">file://$REPO/branches/private_1/tools</a> tools<br>
echo "change made on private_1" >> tools/file.txt<br>
svn commit -m "change made on private_1" tools<br>
svn update tools<br>
<br>
echo "Switch to devel branch and make an conflicting change"<br>
svn switch <a class="moz-txt-link-freetext" href="file://$REPO/branches/devel/tools">file://$REPO/branches/devel/tools</a> tools<br>
echo "change made on devel" >> tools/file.txt<br>
svn commit -m "change made on devel" tools<br>
svn update tools<br>
<br>
echo "Merge to devel"<br>
svn merge --reintegrate --accept postpone
<a class="moz-txt-link-freetext" href="file://$REPO/branches/private_1/tools">file://$REPO/branches/private_1/tools</a> tools<br>
<br>
echo "Resolve conflict and commit"<br>
echo "This is a file" > tools/file.txt<br>
echo "resolved changes" >> tools/file.txt<br>
svn resolve --accept working tools/file.txt<br>
svn commit -m "Merged changes from private_1" tools<br>
svn update tools<br>
<br>
svn log -g tools<br>
<br>
echo "Try to repeat the merge to devel"<br>
svn merge --reintegrate --accept postpone
<a class="moz-txt-link-freetext" href="file://$REPO/branches/private_1/tools">file://$REPO/branches/private_1/tools</a> tools<br>
<br>
<br>
Mark Phippard wrote:
<blockquote
cite="mid:ff892c5d0807071435u2b180370sfc483232bd02dbcf@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Jul 7, 2008 at 2:41 PM, Mark Phippard <a class="moz-txt-link-rfc2396E" href="mailto:markphip@gmail.com"><markphip@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Mon, Jul 7, 2008 at 10:20 AM, Colm Aengus Murphy
<a class="moz-txt-link-rfc2396E" href="mailto:colm.murphy@s3group.com"><colm.murphy@s3group.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I committed all changes (including the change to the dir at the root of the
project). I can see the details of the merge using svn log -g (or using
Tortoise SVN repo browser).
The only difference between the two tests was that in the second test the
merged file had a conflict.
</pre>
</blockquote>
<pre wrap="">Can you create a reproduction recipe? Ideally a script/batch file
that creates a repository, loads initial content, and then runs the
commands that leads to the problem.
</pre>
</blockquote>
<pre wrap=""><!---->
It occurs to me that this is actually the expected behavior. Of
course it is not the ideal or desired behavior, but it is what we
would expect. I am going to try to put together a blog post that
explains in more detail and will post link when I have it.
You really need to delete and recreate branches after they are
reintegrated for merges to continue to DTRT.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
---------------------------------------------------------------------
Colm Aengus Murphy, Tel : +353 1 2911000
Release Manager, Direct Tel: +353 1 2911373
Consumer Mobile,
Silicon & Software Systems, Fax : +353 1 2911001
South County Business Park,
Leopardstown, E-mail: <a class="moz-txt-link-abbreviated" href="mailto:colm.murphy@s3group.com">colm.murphy@s3group.com</a>
Dublin 18. WWW : <a class="moz-txt-link-abbreviated" href="http://www.s3group.com">www.s3group.com</a>
Ireland
---------------------------------------------------------------------
</pre>
<H6><BR><HR>
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
<BR><HR><BR></H6></body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jul 7, 2008 at 2:41 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, Jul 7, 2008 at 10:20 AM, Colm Aengus Murphy
> <co...@s3group.com> wrote:
>
>> I committed all changes (including the change to the dir at the root of the
>> project). I can see the details of the merge using svn log -g (or using
>> Tortoise SVN repo browser).
>> The only difference between the two tests was that in the second test the
>> merged file had a conflict.
>
> Can you create a reproduction recipe? Ideally a script/batch file
> that creates a repository, loads initial content, and then runs the
> commands that leads to the problem.
It occurs to me that this is actually the expected behavior. Of
course it is not the ideal or desired behavior, but it is what we
would expect. I am going to try to put together a blog post that
explains in more detail and will post link when I have it.
You really need to delete and recreate branches after they are
reintegrated for merges to continue to DTRT.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jul 7, 2008 at 10:20 AM, Colm Aengus Murphy
<co...@s3group.com> wrote:
> I committed all changes (including the change to the dir at the root of the
> project). I can see the details of the merge using svn log -g (or using
> Tortoise SVN repo browser).
> The only difference between the two tests was that in the second test the
> merged file had a conflict.
Can you create a reproduction recipe? Ideally a script/batch file
that creates a repository, loads initial content, and then runs the
commands that leads to the problem.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by Colm Aengus Murphy <co...@s3group.com>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Mark,<br>
<br>
See comments below.<br>
<br>
Regards<br>
<br>
Colm A<br>
<br>
Mark Phippard wrote:
<blockquote
cite="mid:ff892c5d0807070715t64e2dfafs5ad7ad50383b353c@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Jul 7, 2008 at 6:44 AM, Colm Aengus Murphy
<a class="moz-txt-link-rfc2396E" href="mailto:colm.murphy@s3group.com"><colm.murphy@s3group.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">(it does however update the top level directory with the details of the
merge even though no merge was necessary which is a separate issue)
</pre>
</blockquote>
<pre wrap=""><!---->
That is the expected behavior as it still marks the revisions that
have occurred in the repository since the last merge.
</pre>
<blockquote type="cite">
<pre wrap="">In the second test the file was edited in both devel and user branches but
this time in the same part of the file.
When the user branch was merged using "svn merge --reintegrate" svn flags a
conflict. I manually resolve the conflict and commit the changes.
This time if the merge command is repeated at a later stage svn doesn't seem
to notice that the merge already took place and flags a conflict.
Is this a bug ?
I'm using svn 1.5.0 on RHEL4 (the same problem is also seen using svn 1.5.0
on win32)
</pre>
</blockquote>
<pre wrap=""><!---->
Did you commit the change to the <a class="moz-txt-link-freetext" href="svn:mergeinfo">svn:mergeinfo</a> property when you
committed the first merge? This would have been set at the root of
your project you merged into. If you only committed the changed file,
then the merge tracking information would not have been recorded. You
should be able to see this via svn log or diff of the commit of the
merge.
</pre>
</blockquote>
I committed all changes (including the change to the dir at the root of
the project). I can see the details of the merge using svn log -g (or
using Tortoise SVN repo browser).<br>
The only difference between the two tests was that in the second test
the merged file had a conflict.<br>
<br>
<pre class="moz-signature" cols="72">--
---------------------------------------------------------------------
Colm Aengus Murphy, Tel : +353 1 2911000
Release Manager, Direct Tel: +353 1 2911373
Consumer Mobile,
Silicon & Software Systems, Fax : +353 1 2911001
South County Business Park,
Leopardstown, E-mail: <a class="moz-txt-link-abbreviated" href="mailto:colm.murphy@s3group.com">colm.murphy@s3group.com</a>
Dublin 18. WWW : <a class="moz-txt-link-abbreviated" href="http://www.s3group.com">www.s3group.com</a>
Ireland
---------------------------------------------------------------------
</pre>
<H6><BR><HR>
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
<BR><HR><BR></H6></body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with merge tracking in 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jul 7, 2008 at 6:44 AM, Colm Aengus Murphy
<co...@s3group.com> wrote:
> (it does however update the top level directory with the details of the
> merge even though no merge was necessary which is a separate issue)
That is the expected behavior as it still marks the revisions that
have occurred in the repository since the last merge.
> In the second test the file was edited in both devel and user branches but
> this time in the same part of the file.
> When the user branch was merged using "svn merge --reintegrate" svn flags a
> conflict. I manually resolve the conflict and commit the changes.
> This time if the merge command is repeated at a later stage svn doesn't seem
> to notice that the merge already took place and flags a conflict.
>
> Is this a bug ?
>
> I'm using svn 1.5.0 on RHEL4 (the same problem is also seen using svn 1.5.0
> on win32)
Did you commit the change to the svn:mergeinfo property when you
committed the first merge? This would have been set at the root of
your project you merged into. If you only committed the changed file,
then the merge tracking information would not have been recorded. You
should be able to see this via svn log or diff of the commit of the
merge.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org