[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New invoke-diff-cmd feature: --svn_cfg-file and --svn-cfg-file-query

From: Gabriela Gibson <gabriela.gibson_at_gmail.com>
Date: Thu, 31 Oct 2013 18:06:39 +0000

On 30/10/13 17:21, Julian Foad wrote:
> This new config-file feature. I think the basic idea is totally
> needed: to be able to configure that different diff
> programs (and/or with different arguments) should be invoked for
> different kinds of files. For example: use oodiff[1] for Open
> Document Text docs, ImageMagick "compare"[2] for images,
> and "kdiff3" for plain text files and everything else.

Also, adding the internal svn diff/merge as an option would also be
useful -- for example, when I merged my branch initially, to my horror,
kdiff3 showed me 30 conflicts, but the internal svn merge only had 2
conflicts (for which I was very grateful!)

So being able to select a visual tool only when you really need
it instead of getting prompted 30 times is preferable, likewise,
as a bonus service, if svn could the leg work for the user and
select the best merge tool to use that would be great.

If kdiff3 finds 30 conflicts and svn merge only produces 2, it
would save a lot of time if svn should inform me of that fact
and, make the optimal choice for me, maybe even interactively if
I ask it to. (Say, lets' call this feature 'opti-merge') Not
saying this kind of thing is part of this feature, but looking
ahead I can see something like that building on the diff-config
file concept.

As an aside (because it's handy to have) here is the merge of my
branch that produced this situation:

svn co -r r1526439 https://svn.apache.org/repos/asf/subversion/trunk/ trunk
svn co -r r1502389

$ kdiff3 --version
Qt: 4.8.4
KDE Development Platform: 4.10.5
kdiff3: 0.9.97 (32 bit)

>> There are now two optional, internal switches to the invoke-diff-cmd
>> --svn_cfg-file and --svn-cfg-file-query.

> Maybe you did it that way because it meant less code churn or an
> easier starting point for you?

I coded this pretzel because it kept the the patch small and made
changing svn.c unnecessary, and so makes it easier to review
given that it's just a proof on concept demo.

> At the very least a filename pattern with wildcards is
> needed (for precedent, see the auto-props configuration).

> More than that, I think it would be nice to be able to match on
> the value of svn:mime-type and/or other conditions to make it a
> bit more powerful than just filenames, but just filename matching
> would be powerful enough initially.


> You mentioned to me that you have specific ideas about why you
> want a separate config file rather than embedding the
> configuration in the '~/.subversion/config' file like we do with
> autoprops configuration. Basically it's because diff preferences
> can vary per project, which I agree with. Could you elaborate a
> bit, here?

* It's safer and easier to just tell svn which diff-config file
   to employ, at the point of use. Every time someone edits or
   swaps out the ~/.subversion/config file, they run the risk of
   mistyping or miscopying.

   Also, even if it only takes 2 minutes to set up, it this occurs
   1000 times, that's 33 man hours wasted on a boring task.

* ~/.subversion/* isn't versioned since it's not part of a trunk
   but the personal workspace set-up.

   There may be situations where different setups are required --
   users may work on more than one trunk revision or also on
   different projects that use svn.

* The current design is easily managable and also scriptable,
   moreover it's versionable if that is desired.

* Individual users may have different ideas as to what constitutes a
   decent diff program, so this accommodates everyone.

At this point, it's probably best if we split the branch up here,
and just have the invoke-diff-cmd branch for the basic diff part,
ready to go into trunk once everyone is happy with it, and make
two new branches: invoke-merge-cmd-feature and diff-config-feature.

Received on 2013-10-31 19:05:37 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.