I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py when merging changes between branches and trunk. That's very important if we're going to avoid merge hell. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py when merging changes between branches and trunk. That's very important if we're going to avoid merge hell.
The plan isn't to do what the TortoiseSVN docs call a "Range of Revisions" merge, but rather what those docs call "Merging Two Different Trees". Since in effect that just copies the file from the trunk to the release branch, there isn't any chance of merge hell, if I understand what you mean. This approach also minimizes the chance that the code will break, since the code is unchanged from the code being tested on the trunk. Is there any reason to use svnmerge.py for a tree/tree merge? --Beman PS: Subversion 1.5 will fold in the svnmerge.py merge tracking functionality. It should ship fairly soon. TortoiseSVN will release a new version at the same time that also supports merge tracking. See http://blogs.open.collab.net/svn/ for more information.
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py when merging changes between branches and trunk. That's very important if we're going to avoid merge hell.
The plan isn't to do what the TortoiseSVN docs call a "Range of Revisions" merge, but rather what those docs call "Merging Two Different Trees".
Do I have to learn about TortoiseSVN in order to understand what you're saying? I don't really use Windows for development anymore.
Since in effect that just copies the file from the trunk to the release branch, there isn't any chance of merge hell, if I understand what you mean. This approach also minimizes the chance that the code will break, since the code is unchanged from the code being tested on the trunk.
Is there any reason to use svnmerge.py for a tree/tree merge?
Probably, especially if you're ever merging back and forth between two trees.
--Beman
PS: Subversion 1.5 will fold in the svnmerge.py merge tracking functionality.
Yes I know.
It should ship fairly soon. TortoiseSVN will release a new version at the same time that also supports merge tracking. See http://blogs.open.collab.net/svn/ for more information. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py when merging changes between branches and trunk. That's very important if we're going to avoid merge hell. The plan isn't to do what the TortoiseSVN docs call a "Range of Revisions" merge, but rather what those docs call "Merging Two Different Trees".
Do I have to learn about TortoiseSVN in order to understand what you're saying? I don't really use Windows for development anymore.
I spent about 20 minutes searching online for documentation or examples of using the merge command to do what is really a copy. I also checked the "Version control with Subversion" book, both paper and online versions. The TortoiseSVN docs are the only place I can find that mentions this use case.
Since in effect that just copies the file from the trunk to the release branch, there isn't any chance of merge hell, if I understand what you mean. This approach also minimizes the chance that the code will break, since the code is unchanged from the code being tested on the trunk.
Is there any reason to use svnmerge.py for a tree/tree merge?
Probably, especially if you're ever merging back and forth between two trees.
But we aren't really merging. We are copying, using the merge command to do the copy because the copy command doesn't have an overwrite option. Hopefully the whole synmerge.py issue will go away once we change over to 1.5. --Beman
on Fri Nov 02 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
David Abrahams wrote:
I hope everyone is using http://www.orcaware.com/svn/wiki/Svnmerge.py when merging changes between branches and trunk. That's very important if we're going to avoid merge hell. The plan isn't to do what the TortoiseSVN docs call a "Range of Revisions" merge, but rather what those docs call "Merging Two Different Trees".
Do I have to learn about TortoiseSVN in order to understand what you're saying? I don't really use Windows for development anymore.
I spent about 20 minutes searching online for documentation or examples of using the merge command to do what is really a copy.
Really a copy? There's been evolution on both the 1.34 release branch and on the trunk since they forked. How would doing a plain copy fix anything? Oh, I see; you're talking about preparing the release branch.
I also checked the "Version control with Subversion" book, both paper and online versions. The TortoiseSVN docs are the only place I can find that mentions this use case.
If you want to copy files from one place to another, it's "svn cp".
Since in effect that just copies the file from the trunk to the release branch, there isn't any chance of merge hell, if I understand what you mean.
What happens when more work is done on the trunk and you find you need to pull just some of it into the release branch?
This approach also minimizes the chance that the code will break, since the code is unchanged from the code being tested on the trunk.
Is there any reason to use svnmerge.py for a tree/tree merge?
Probably, especially if you're ever merging back and forth between two trees.
But we aren't really merging. We are copying, using the merge command to do the copy because the copy command doesn't have an overwrite option.
The way to do that is to have a working copy that contains the branch and the trunk, "svn rm" the branch files, "svn cp" the trunk files over to the branch, then "svn commit"
Hopefully the whole synmerge.py issue will go away once we change over to 1.5.
Oh, it sure will. Unfortunately I'm finding svn to be a bit painful so far, and wondering what to do about it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
PS: Subversion 1.5 will fold in the svnmerge.py merge tracking functionality. It should ship fairly soon. TortoiseSVN will release a new version at the same time that also supports merge tracking. See http://blogs.open.collab.net/svn/ for more information.
See also http://blogs.open.collab.net/svn/2007/10/subversion-15-m.html -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (2)
-
Beman Dawes -
David Abrahams