[Svnmerge] [PATCH] Cache svn output

[Giovanni Bajo]

Rich Williams wrote:

> Ok, well I'll give it a go then -

Thanks!

> should be a chance to brush up
> on my Python skills - I don't suppose you'd accept a re-write
> in Perl would you? :-)

I'd rather not :-)

> I wasn't sure if the config should be in an [svnmerge] section of
> ~/.subversion/config, or in it's own file - sounds like you think it
> should be a separate file? What kind of format - INI style like
> the existing config files?

Yes, it's better to use a separate file, I have no clue whether SVN (or any
other tool grokking .subversion/config) is lenient to unknown INI sections.
They should, but I don't want to go there. BTW, in Windows, the config file
is located at os.path.join(os.environ["APPDATA"], "Subversion", "config").

Use the ConfigParser module to parse the .ini file:

>>> name = os.path.join(os.environ["APPDATA"], "Subversion", "config")
>>> from ConfigParser import ConfigParser
>>> cfg = ConfigParser()
>>> cfg.read([name])
['C:\\Documents and Settings\\rasky\\Application Data\\Subversion\\config']
>>> cfg.get("auto-props", "*.c")
'svn:eol-style=native'


I would also like to see an example of this config file. A simple version
would be:

-----------------------------------
[cmdline]
merge = --bidirectional -F
avail = --log
-----------------------------------

This would allow to later ignore [cmdline] in case we come up with something
more complex (eg. reusing long-option names for key names in the INI, so
that you can do something like bidirectional=True). This version should be
easier to implement and maintain at this point.


> I didn't see any mail about a GUI wrapper, but that sounds like
> a good idea - one of the developers here actually wrote an
> interactive command line script which runs 'avail', filters out
> changes from other developers, then steps through each
> revision letting you decide between - yes: merge it now,
> no: skip it this time and diff: show me the diff. It works really
> well for our way of working. If you think it would be useful,
> I'll ask him if he's willing to share it.
>
> Would you consider adding something like that being built
> into svnmerge as an 'interactive' merge, or would it be better
> kept as an extra step?

The mail about the GUI wrapper is still in my drafts, I haven't completed it
yet. Anyway, I guess it's clear for any svnmerge user that merging is really
an incremental, interactive operation, which does not fit perfectly to
svnmerge's command line, single-command interface. The interactive step
"outside" svnmerge is surely easier to write and maintain, but if you want
to achieve the maximum speed you need to do it *inside* svnmerge, to reuse
all the context information about the server which svnmerge would have to
build only one.

So, to sum it up, I'm in favor of an interactive mode. I guess it could be
an external script, which imports svnmerge and reuse its internals (instead
of popen-ing "python svnmerge.py").
-- 
Giovanni Bajo