Stefan Küng wrote:
> Kevin Puetz wrote:
>> Since svnmerge changed from unix sh to python, it now works nicely on
>> windows, so I've been working on some scripts to hook it into the
>> tortoisesvn dialogs (espescially the commit one, as being able to view
>> diffs right from the commit dialog is a very handy way to review what you
>> just did).
>>
>> However, I can't work out a way to get the log message template passed in
>> to TortoiseProc.exe; quoting embedded whitespace is tough (since I'm
>> calling from cygwin, and thus have two dissimilar quoting rules to fight
>> with) but quoting embedded newlines appears to perhaps actually be
>> impossible (at least google has not yet revealed a way to pull it
>> off...). I don't even really want to think too hard about the general
>> case with non-ascii and other stuff in it :-) Would it be possible to
>> support reading /logmsgfile:path (read from a file)as well as
>> /logmsg:message? That would also be consistent with svn's commandline
>> commit (and thus with what external svn scripts are expecting to feed).
>
> Done in revision 4960.
Thanks. I'll give it a shot tomorrow (it looks like the r4961 nightly is now
up...). It will be nice not to be popping up notepad with the commit
message to cut&paste into the commit window. That was workable, but just
tacky :-)
>> The second thing that would make this *really* slick would be a way to
>> show log messages for a discontinuous set of revisions (svnmerge's
>> notation is start-end,start-end,start-end), and then return the list of
>> selected revisions (printed to stdout in the same notation would work
>> great). But that's probably a bigger change to implement, since it would
>> require the log dialog to make multiple requests to fetch each range of
>> messages.
>
> TSVN is a GUI client and does *never* print stuff to stdout. In fact,
> stdout, stdin and stderr aren't even set up for GUI programs at all
> since they don't have a console window.
Oops. I always forget that they are actually not available (even if called
from a console). You're right, of course. It's just that the tsvn log
dialog would be nearly perfect for svnmerge avail (which already looks a
great deal like a sparse log -v). So the fact that I can't use it irritates
me in a totally unjustified way (See, if it wasn't so good, I'd be less
dissatisfied). Maybe a different sort of automation interface to the tsvn
dialogs could be more suitable for something that wants output back
(perhaps an out of process COM interface)?
Another possibility would be just trying to directly support svnmerge from
'inside' TortoiseSVN (where it ought to be at least moderately
straightforward to get selected revisions back - the existing merge dialog
does this, after all). One could either use boost::python or similar to get
into svnmerge.py (which would probably have to be optional at runtime) or
just use the exe and shell out (not elegant, but also not actually very
complex). Heck, it would probably even be practical to just (re)implement
the algorithm in C++ (svnmerge.py is only 1200 lines, and a big chunk of
that is CLI output formatting).
A merge dialog for svnmerge wouldn't look all that different from what's
already there; the list of revisions is culled to those not already
integrated (or rejected), the selected revisions can be discontinuous, and
the property which stores this info gets updated in the WC after the merge
completes, but that's about it.
However, Tortoise doesn't seem to have any functionality borrowed from
contrib/client side (e.g. svnmerge, MUCC, etc). Is that a deliberate choice
to avoid things that aren't "core subversion", or just a lack of developer
interest? If the latter, maybe I should get a TortoiseSVN build going and
either put up or shut up :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Nov 17 07:51:50 2005