Hello Manu, Thanks for sharing your experience with us!
Emmanuel Blot wrote: > 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. ok > > 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. scary ... > > 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 see your point. However I wonder if we couldn't come up with a useful and compact way to show this information. Could be as simple as: svn:mergeinfo: - sandbox/rework-merging merged eligible - branches/0.11-stable merged eligible With merged/eligible links to the revision log with the corresponding ranges (the tooltip also showing the revision ranges). That list could eventually be pruned from the paths which are no longer existing (or do you really have 30 active branches?) > I've never been a fan of the svnmerge.py script, and hardly used it. Well, at least svnmerge did its job and was never a source of headaches ;-) Actually, svnmerge.py will call 'svn merge', so when using a recent svn you end up with some svn:mergeinfo in any case (e.g. http://trac.edgewall.org/changeset/8222). > 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. That's reassuring - it gives me more incentive to invest some time in this. > > 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.... Understood. But what is the relevance of the version of the Subversion /server/, in this picture? svn.edgewall.org runs Subversion 1.5.1. Is that a problem? -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
