Emmanuel Blot wrote: > Hi, > > >> Thanks for sharing your experience with us! >> > > I found only a little information on merging (I mean, real experiences > about SVN merging), so I thought it could give some hints. > > >> 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 >> > > I'm not sure about the meaning about the eligible keyword here? > I use --show-revs eligible to get information about what can be > merged, but what would be the meaning once the merge operation has > been completed? Is it to differenciate from a user-selected merge > source? >
No, it's just what `svn mergeinfo --show-revs eligible` would show... I was thinking about the repository browser view, here. I suppose you were thinking about the changeset view. There, we could simply show what has been merged, in a way very similar to svn diff, e.g. trunk> svn diff -c8225 ... Modified: svn:mergeinfo Merged /branches/0.11-stable:r8215-8216 >> That list could eventually be pruned from the paths which are no longer >> existing >> > > I think that would make sense if "no longer exist" is not an absolute > time, but a time relative to the merge operation itself, i.e. the > source branches that still exist at the time of the merge operation > that created the changeset. I'm not sure this shortcut could be > applied for all SVN projects though. > There still should be an option to see the actual source branches > (even once they have been deleted). > > >> (or do you really have 30 active branches?) >> > > Let's see: 24 product more or less active branches, 44 developer > active branches in our main repository (we have 10 of them) > > svn pg svn:mergeinfo on /trunk currently returns 373 lines, knowing > that there would be over 1000 of them if I hadn't had to remove > svn:mergeinfo properties in the early 1.5.x times ;-) > Ok, I see... So we really need to imagine something that can scale. > >> 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? >> > > It has never been an issue for us at least: we've used 1.5.1 (Debian) > for over 1 year, then I've upgraded the server to 1.5.6. I'm waiting > to upgrade the server to 1.6.2, as I'd like to benefit from some of > the new features such as > http://subversion.tigris.org/svn_1.6_releasenotes.html#filesystem-improvements > > Good to know. > However, as I've been disappointed more than once with SVN 1.5.x > clients, I've been refraining from upgrading the server up to now: I > want to be sure it is stable enough before upgrading. > > Let me know if you need some beta tester for this feature: I could > create a "ghost" Trac environment pointing onto the actual SVN > repository to perform some rendering tests. > > Ok, fine! -- 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 -~----------~----~----~----~------~----~------~--~---
