From: Alan E. <ala...@gm...> - 2010-08-30 21:10:41
|
In my attempt to refactor, I made it a bit simpler. There were some unused variables and arguments in your original design. I also used ProcessBuilder instead of the old getRuntime().exec(), which allows for merging of stdout and stderr. Which is also what I did, to reduce the number of threads I needed to create. It seems to perform well, but I didn't bother with VFS code, since I still don't really understand how to use that API effectively. So it assumes everything is on the local file system. But do you think this Command class belongs in CommonControls.io? On Sun, Aug 29, 2010 at 4:06 PM, Marcelo Vanzin <va...@us...> wrote: > On Sun, Aug 29, 2010 at 3:17 PM, Alan Ezust <ala...@gm...> wrote: >> Anyway, I made a first attempt at GitPlugin. >> The process.waitFor() seems to cause a deadlock in jEdit right now, and >> I'm not exactly sure why. I will have to debug it further. But once >> that is working, I can use that as a model for writing the Bzr entries >> filter too... > > For these command line-based SCMs it might be useful to refactor > P4Plugin's "Perforce" class into something more generic. It's > basically a wrapper around a subprocess. I started doing it some time > ago but as usual turned my attention to something else before I > finished... > > -- > Marcelo Vanzin > mmv...@gm... > "Life's too short to drink cheap beer." > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |