[Svnmerge] svnmerge rewritten in Python

[Jim Fulton]

Giovanni Bajo wrote:
> Jim Fulton <jim at zope.com> wrote:
> 
> 
>>>This is interesting. This behavior, getting the return status
>>>as a result of a close of a file returned by popen4, is inconsistent
>>>with the Python library documentation.
> 
> 
> I read this in the os.popen documentation:
> 
> """
> The exit status of the command (encoded in the format specified for wait()) is
> available as the return value of the close() method of the file object, except
> that when the exit status is zero (termination without errors), None is
> returned
> """
> 
> So I'd say this is documented, but it does not work under Linux for some
> reason. There, you need to use wait(). Maybe it's a difference on how the pipes
> work at the kernel level. Module subprocess was added exactly to abstract these
> issues, and it does that very well. I just did not want to use it because I
> want to retain Python 2.0 compatibility.

The documentation for popen2-popen4 says:

"These methods do not make it possible to retrieve the return code from the child
processes. The only way to control the input and output streams and also retrieve
the return codes is to use the Popen3 and Popen4 classes from the popen2 module;
these are only available on Unix."

The subprocess documentation seems a bit ambiguous.  It doesn't matter this issue
directly.  It says you can call wait on a popen object to get the return status,
but is says the retcode attribute is only available on unix.

Hopefully, this is just a documentation issue.

> 
>>>I still think it would be cleaner to get data back from
>>>the apis than to parse output.
> 
> 
> 
> Yes, generically speaking, it's better to get access to data without
> marshalling everything to strings and back everytime. But for this script, I
> believe it's much better to keep the code size low, the external dependencies
> as minimum as possible, and the compatibility as high as possible. Using the
> svn client is a simple way to achieve this.

ok, fair enough, especially since you are leading the development. :)

> Notice we already have a dark corner, see get_repo_root which is ugly and slow.
> If those cases grew in number, I'd be more in favor of using the bindings.

They don't help with this, AFAICT.  I was going to have to do the same sort
of hack.  This is really odd, since subversion itself is able to compute and
deal with repository-relative paths.

...

>>>I strongly recommend automated tests included with the script --
>>>preferably as doc tests.  You should be able to get an idea of the
>>>testing approach I was following in my script.
> 
> 
> 
> Sure, testing is fundamental. I tend to do unittest mainly, but I'll play with
> doctests for this. I'm gonna have a full weekend, so let's see if I find some
> time on monday.

Cool.

> BTW, given also the other discussions and the improvements we are planning, I'm
> going to put the script in a SVN repo of mine to handle development easier (I
> feel uncomfortable working without patches and SCM).

Makes sense.

> Thanks for your feedback, it is really appreciated!

Great.

Jim