[Svnmerge] svnmerge and different flavors of sh

[Blair Zajac]

Jim Fulton wrote:
> Blair Zajac wrote:
> 
>> Jim Fulton wrote:
>>
>>>
>>> FWIW, I'd be happy to contribute toward a Python version of svnerge.
>>> This should increase portability, performance, and maintainability.
>>>
>>> Jim
>>
>>
>>
>> Hi Jim,
>>
>> That would be great.
>>
>> I would just start on it and send it along to the mailing list for 
>> feedback for eventual inclusion into Subversion's main repository, 
>> which either I can do.
> 
> 
> ok
> 
>> BTW, a good place to check out on writing a Subversion client that 
>> purely uses the Python bindings and doesn't fork out anything is this 
>> script, which took a decent amount of work to figure out, as there's 
>> almost no documentation anywhere, except for pydoc, Subversion's 
>> include files and Googling the mailing lists:
>>
>> http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn_export_empty_files.py 
> 
> 
> 
> I have 2 reservations about using the Python subversion bindings:
> 
> 1. As you say: "there's almost no documentation anywhere, except for pydoc,
>    Subversion's include files and Googling the mailing lists". :/
> 
> 2. I doubt that subversion-python is widely installed.  For example, It's
>    not included in the online binaries for Fedora:
> 
>    http://dag.wieers.com/packages/subversion/
> 
>    (It also doesn't seem to be available in the standard FC1 yum
>    repository. Yes, I need to upgrade from FC1. :)
> 
> I'm inclined to shell out for subversion operations.  We can, at least,
> avoid shelling out for string operations. :)
> 
> I'll isolate the subversion access in such a way that a more direct
> approach can be plugged in if desired.
> 
> (BTW, as I mentioned before I doubt this will have much speed benefit,
> except in the case of local repositories, as I think most time
> will be taken doing network I/O.)
> 
> Jim
> 

Well, in our open source world, the person who does the work gets to say how it 
gets done :)

I don't have any strong feelings with the bindings, but there is a perception in 
the Subversion group that using the bindings is better than shelling out.  Also, 
they've received a large amount of work, such as one of the Google Summer of 
Code projects was to improve the Python bindings, so I wouldn't like to see new 
projects use shells when bindings can be used.

In this case, as we're not doing much or pulling information from the repository 
that is hard to get via a shell, so we could go either way.

Regards,
Blair