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

Re: svnmerge and tortoise

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2005-11-17 19:54:04 CET

Kevin Puetz wrote:

> 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)?

I don't think I'll ever implement a COM interface for TSVN. For
automating stuff, the CL client is much better suited. Also, if you're
working with python, you could use the python bindings of Subversion -
then you have access to all Subversion API's you want.

> 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).

"only 1200 lines" - that's BIG! You have to consider that python
commands are much more powerful than plain C/C++ - so you'd have to
multiply the amount of lines needed in C/C++ to do the same. And usually
python has libraries which aren't part of the OS, so we'd have to look
for such libs and include them in the TSVN distro.

> 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.

Maybe you can summarize what svnmerge actually does?

> 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 :-)

It's not that those features aren't useful for TSVN. But those are
additional features, and I have enough to do keeping TSVN up to date
with all the changes inside the Subversion core. Another thing is that I
don't really know perl/python/Unix-sh/... so those scripts aren't really
helping me. The description of those is limited (to say the least), and
trying to find out what and how they do things would take too much time,
considering that I don't really know the language they're written in.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Nov 17 19:55:46 2005

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

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