On 10/22/07, Daniel L. Rall <dlr@finemaltcoding.com> wrote:
> > Ugh :-(. That's a tough one. The simplest answer for now might be to
> > notice whether there were copies/moves during the dry run, trap the
> > error from the external patch program, see if the error applies to any
> > of the putatively copied/moved items, and transform it into an
> > "application deferred" warning instead. I realize that's lame, but
> > it's the best I can come up with right now.
>
> This is a similar approach to what we use for dry-run merges. It's lame,
> but better than nothing.
That sounds very tricky. For example, GNU patch prompts the user for
a direction to take when such thing happen. Does that mean we're also
going to wrap the program's input stream and answer on behalf of the
user when the prompting questions match a particular pattern? That
sounds like a lot of code specific to one external program and again
very hairy.
How about temporarily spawning the files the external tool needs for
the time it runs? That could involve spawning a whole tree.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 22 22:07:28 2007