Re: Bug with large output on vc commands



So the issue was actually a bzr issue again (restraining self from bad pun...)
It's using status instead of a MUCH quicker info to check if this directory is a bzr branch.
It was blocking if the return value from status was large (ie lots of changes in the branch)
I have confirmed that the exit codes from info are non-zero if the directory is not a bzr branch, so this works successfully.

diff --git a/meld/vc/bzr.py b/meld/vc/bzr.py
index de16784..4a71e13 100644
--- a/meld/vc/bzr.py
+++ b/meld/vc/bzr.py
@@ -75,7 +75,7 @@ class Vc(_vc.CachedVc):
     def resolved_command(self):
         return [self.CMD] + self.CMDARGS + ["resolve"]
     def valid_repo(self):
-        if _vc.call([self.CMD, "status"], cwd=self.root):
+        if _vc.call([self.CMD, "info"], cwd=self.root):
             return False
         else:
             return True


As an aside, I was unaware of os.devnull - is this safe for cross platform?
--
Louis



On 11 December 2012 06:06, Kai Willadsen <kai willadsen gmail com> wrote:
On 10 December 2012 12:59, louis <louis obsidian com au> wrote:
>
> I was finding that large projects when doing merges would fail to open in
> merge.
>
> After a lot of digging, the below patch fixes it. Essentially,
> subprocess.call blocks when output is directed to a pipe if the output is
> too large.
> Annoyingly subprocess has no 'ignore' flag for output... so the below seems
> the best from my reading.
>
> Figured given it's small it's fine to send it straight to the list :)
>
> diff --git a/meld/vc/_vc.py b/meld/vc/_vc.py
> index ef556b0..03dced6 100644
> --- a/meld/vc/_vc.py
> +++ b/meld/vc/_vc.py
> @@ -255,5 +255,10 @@ def popen(cmd, cwd=None):
>
>  # Return the return value of a given command
>  def call(cmd, cwd=None):
> -    return subprocess.call(cmd, cwd=cwd, stdout=subprocess.PIPE,
> -                           stderr=subprocess.STDOUT)
> +    proc = subprocess.Popen(cmd, cwd=cwd, stdout=subprocess.PIPE,
> +            stderr=subprocess.STDOUT)
> +    while proc.poll() is None:
> +        # We don't really care about the output, but we need to read the
> pipe
> +        # or this will block
> +        proc.communicate()
> +    return proc.returncode

Thanks for the patch, but unfortunately this just raises more
questions! _vc.call() is only supposed to be used (and as far as I can
see, only is used) as quick verification based on return code. Which
usage is actually returning any significant amount of data?

As for the patch, I'd probably rather solve the problem by explicitly
dumping the output, like:

    def call(cmd, cwd=None):
        NULL = open(os.devnull, "wb")
        return subprocess.call(cmd, cwd=cwd, stdout=NULL, stderr=NULL)

...but since I can't reproduce the bug, I can't actually test this.
Any details on how to reproduce this would be appreciated.

cheers,
Kai



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]