About my svn merge experience: I've (we've) been intensively using this feature since early 1.5.0 SVN release (not w/ edgewall.org).
SVN used to suffer from several major bugs with svn:mergeinfo management: any SVN tool before 1.5.5 used to create invalid svn:mergeinfo properties. 1.5.3 being the worst of all, making the repository nearly unusable. 1.6.0 also shown a regression on this topic. Fixed in 1.6.1, and 1.6.2 seems Ok AFAICT. The problem is that once *one* file is assigned a svn:mergeinfo property, the property last forever, and is replicated to/from any branch that contains the file. If you do partial merge (any operation of merging a whole changeset from/to a whole tree), svn:mergeinfo properties are assigned to subdirectory / files. The common scenario is that you create a branch from a source branch that contains one or more files tagged with a svn:mergeinfo property. Once you merge back the branch to the original source branch (svn merge --reintegrate), the svn:mergeinfo property of this file is updated, even if you have not touched this file in your development branch. It looks like a viral behavior, as svn:mergeinfo property set keeps growing in a repository, and is never shrunk down. I've even ended up writing a script to remove the svn:mergeinfo properties that used to pollute our branch, till SVN 1.5.5, as those properties were sometimes invalid. Anyway, since 1.5.5 (and 1.6.1), SVN seems to manage the svn:mergeinfo properties the right way. However it keeps polluting the repository view in Trac as Trac keeps rendering this property. *I do think Trac should not try to render this property, at least in the default view*. The best option I see is that Trac should show if a svn:property exists, but should hide the actual property value (which ends up to be very, very long, about 30 lines in our own trunk...), and offer a link to render the property value, i.e. the mergeinfo sources. I've never been a fan of the svnmerge.py script, and hardly used it. However we are now using svn merge --reintegrate and svn merge -r x:y several times a day with no particular issue, and it works as expected. There's one terrible lack though: the server should be able to detect the svn client version to reject invalid clients, such as the awful 1.5.3 series: if *one* svn invalid client sends incorrect svn:mergeinfo properties to the server, it leaves the repository within an unmanageable state: the admin needs to clean up those properties as soon as possible, or valid clients start to branch and bring the invalid properties within their own branches, then merge it back to the source branch: it may takes weeks to finally remove invalid svn:mergeinfo properties once they are dispatched in other branches then merged back. And sometimes, there are no other choice than deleting the property itself, which may jeopardize future merge operations.... Cheers, Manu --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
