Patch for preliminary Mercurial integration in kdevplatform
Fabian Wiesel
fabian.wiesel at fu-berlin.de
Sat Mar 14 12:46:49 UTC 2009
On Fri, 13 Mar 2009 22:14:50 +0100
Andreas Pakulat <apaku at gmx.de> wrote:
> Thats for example wrong. If rawOutput contains non-ascii text this
> will break horribly.
I admit, I haven't thought about non-single-charsets. Fixed that in the
new version (now submitted over commited).
Speaking about multi-byte character sets, doesn't the approach in
ProcessLineMaker has its own problems?
First one, what happens, when the output is not terminated by a final
newline? As it currently stands, the final will not be passed by
output().
Second, do we care about about 2-byte (or four-byte) character sets?
> [...]
> Just curious whats the point of using std::auto_ptr here?
> > +DVCSjob* MercurialExecutor::init(const KUrl &directory)
> > +{
> > + std::auto_ptr<DVCSjob> job(new DVCSjob(vcsplugin));
> > +
> > + if (!prepareJob(job.get(), directory.toLocalFile(),
> > MercurialExecutor::Init)) {
> > + return NULL;
> > + }
> > +
> > + *job << "hg" << "init";
> > +
> > + return job.release();
>
> Or especially here as you're giving it away anyway.
I like RAII, and have an aversion of unowned pointers.
As I gathered from the code DVCSPlugin, a job has to be deleted unless
it is started. Then the job itself will take ownership. When I return
the pointer, I will relinquish the ownership to the caller.
Should prepareJob() (or anything else before returning the pointer fail,
I have to delete the pointer.
I'd rather do that by an RAII-object than manually, especially since it
is practically the same amount of code. Doing so even in a three-liner
is just a matter of consistency.
Of course, I can change that, if it goes against code-style here.
> Interesting, mercurial supplies \0 as separation character. Thats
> rather nice for stdin/stdout communication.
Well, mercurial doesn't do that by itself, but it can be motivated to
do so by providing a template how the output should look like.
Unfortunatly, that only works for the log-output.
> Other than that the code seems ok (I didn't do a really deep review
> as I don't know too much about the dvcs stuff). Are you willing to
> maintain this if it goes into kdevplatform? Do you already have an
> svn account?
Generally, yes. I could maintain it. I don't have an SVN account yet.
Fabian
More information about the KDevelop-devel
mailing list