[Svnmerge] Re: Patch for non-reflected bidirectional merging support
Raman Gupta
raman at rocketraman.com
Sat Aug 27 18:02:24 PDT 2005
Raman Gupta wrote:
> Raman Gupta wrote:
>
>>Hi all,
>>
>>I have attached two patches. The first is incidental and fixes a couple
>>of bugs svnmerge that I found while testing. These bugs are:
>>
>>1) The get_all_integrated_revs method was not being passed the
>>BRANCH_DIR, causing the integrated revisions for some merge target
>>branches to be lost when tracking integrated revisions for multiple targets.
>>
>>2) The merge algorithm did not revert changes to the svn-integrated
>>property for each range being merged, which caused a conflict if more
>>than one range being merged contained a change to the svn-integrated
>>property.
>>
>>The second, and far more interesting, patch adds merge-point tracking.
>>This improves the bi-directional merging support of svnmerge by
>>preventing reflected changes from being merged. See here for initial
>>discussion fo the problem, and a description of the solution implemented
>>in the patch:
>>
>>http://www.orcaware.com/pipermail/svnmerge/2005-August/000000.html
>
> I have attached a fix for the previous svnmerge-bidirectional.patch
> called "svnmerge-bidi-fixpaths.patch". This patch depends on, and should
> be applied after, the original "svnmerge-bidirectional.patch" patch.
>
> The fix is for branches that are in a subdirectory, such as a "branches"
> directory as recommended by the svn book. Because of the necessary evil
> of dot-files to track merge-points, paths need to be munged (slashes are
> replaced with underscores) when reading/writing.
>
I found another bug with the bidirectional merges support
implementation. During my testing I had checked out the branch and trunk
at the same time for simplicity. However, in normal operation one
switches between source versions. That means that when the source is
being checked for merge points from the target, the target branch (which
is usually ".") has to be converted to a full local path first.
I have attached the simple patch for this problem, called
"svnmerge-bidi-fullpath.patch". This patch depends on the previous
bidirectional patches. The order of application should be:
1) svnmerge-bidirectional.patch
2) svnmerge-bidi-fixpaths.patch
3) svnmerge-bidi-fullpath.patch
If anyone wants a single combined patch, let me know.
Cheers,
Raman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[raman ~]$ sha1sum svnmerge-*.patch
0951f53410f3183bd84ec9bd2d67916d770186ce svnmerge-bidi-fullpath.patch
509e212f8f12d4cc990faf068982ead2afefe0a1 svnmerge-bidi-fixpaths.patch
de195d1d8de0450137f1c393914231088db9bec3 svnmerge-bidirectional.patch
e637ee3f2f13692adf0db8ce615b487ec2a9f123 svnmerge-bugfixes.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDEQrYaEIcY+eF4JQRAiHxAJ9hwevQ5IVmJQzdjzLUkoqhOowM4QCeO8vs
kMtEYy2jWXXP4ONvJddSkTs=
=sO4j
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svnmerge-bidi-fullpath.patch
Type: text/x-patch
Size: 998 bytes
Desc: not available
Url : /pipermail/svnmerge/attachments/20050827/a3f232bd/attachment.bin
More information about the Svnmerge
mailing list