On Wed, Mar 09, 2011 at 05:21:34PM -0700, Paul Madden wrote: > I'd like to know whether there's a way -- or whether it would be reasonable to > request a feature to provide a way -- to ask svn supply the original filename > to > an external diff3 tool. > > I use xxdiff to view diff info from subversion, via a command-line-argument > translation script. > > In an "svn update" test, these arguments were passed to my script: > > --> -E > --> -m > --> -L > --> .mine > --> -L > --> .r1329 > --> -L > --> .r1339 > --> .svn/tmp/tempfile.tmp > --> .svn/text-base/qsubfim.frost.svn-base > --> .svn/tmp/text-base/qsubfim.frost.svn-base > > This isn't so bad, as the original filename (qsubfim.frost) actually appears > in > two of the filenames. It would be nicer if an extra argument supplied the > actual > original filename, though, so I could display it in the xxdiff titles without > trying to extract it from one of the filenames. > > But the arguments supplied in an "svn merge" situation are less helpful: > > --> -E > --> -m > --> -L > --> .working > --> -L > --> .merge-left.r1330 > --> -L > --> .merge-right.r1339 > --> .svn/tmp/tempfile.4.tmp > --> /tmp/tempfile.14.tmp > --> .svn/tmp/tempfile.tmp > > The file actually under examination is called "batchTemplate-fim" so, unless > you > immediately recognize the code in the xxdiff window, there's no way to know > what > you're looking at: No command-line arguments provided by svn tell you. > > Someone asked about this in September 2009, but I didn't see a response: > http://svn.haxx.se/users/archive-2009-09/0420.shtml. I also searched for > tickets, but didn't find anything applicable -- though I could easily have > missed it given the ticket volume. > > I'd be grateful for any information, whether it's a solution or workaround I > could implement myself, a reason why this is a bad idea and I should give up > on > it, or encouragement to file a feature request. > > Thanks in advance, > paul
Paul, please file an issue in our tracker if you have the time: http://subversion.tigris.org/issue-tracker.html And add a link from the issue to your post in the archives, as required by our bug reporting guidelines. This way the issue won't fall through the cracks again. You'll also have a way to monitor progress on the issue (the issue submitter gets email for every update made to the issue -- and others can add themselves to the issue's Cc list to receive the same.) Thanks!
