On 10/22/07, Charles Acknin <charlesacknin@gmail.com> wrote:
> 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.
Writing to the wc during --dry-run seems like a bad idea. I'd rather
drop dry-run functionality than need to do this. (In fact in the
interest of actually finishing this increasingly hairy feature, maybe
you should punt --dry-run until later?)
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 23 00:26:43 2007