harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: Re: [classlib][pack200] Status update (again)
Date Thu, 23 Nov 2006 01:36:17 GMT
On 23/11/06, Nathan Beyer <nbeyer@gmail.com> wrote:
> Why would you need to do anything to the SVN meta files (.svn)? DRLVM
> doesn't run on MacOS either, so how do you verify your code builds and
> test run within the Harmony codebase?

Because I don't want to build the java/util/* when I'm working on the
org/apache/harmony/pack200 code. In fact, it gets in the way of doing
the development because there are a number of other unsatisfiable
dependencies without working on the rest of the codebase. If I delete
the java/ directory from my system, SVN says that I've deleted the
java/ directory, and there's the danger that any patch I've provided
would end up deleting the java/ directory of a commiter instead. So I
edit the .svn/entries file to make it look like there isn't a java/
directory there at all, which keeps everyone happy.

As for building and tests run with Harmony -- I don't know that. I
can't know that, either. But I can test that the code that I've
written runs and does what it should providing that the underling
java.io.InputStream/java.util.jar.JarEntry classes do what they say
they should. I'm testing the pack200 code with respect to the contract
of the public API classes, and I'm writing the tests to know whether
they fall over or not so that if there are problems (either with my
code or the current harmony java.util.jar* implementations) we can
find and fix them. I'm not using the harmony build.xml or any of those
processes; I'm just doing the compilation and relying as much as
possible on the Java 1.3 APIs, because a key goal is being able to
reuse this on older VMs and embedded in other (read: non-Harmony)
projects. It's therefore essential that it *doesn't* rely on any
Harmony-specific behaviour, though of course, it should also co-exist
with Harmony.

> Have you tried just doing an SVN export (no meta files) delete what
> you want to ignore, work on what you want to work on in the IDE of
> choice. Once you're ready for a update, check out/update the latest
> archive module code, in a separate folder, do a manual merge/overlay.

That's pretty much the same as I'm doing at the moment, though, except
I'm doing in-place editing of the pack200 code and merging out of the
files that are there. It's supposed to make it easier for doing diffs
and patches, but I've yet to see that benefit.

The thing is, I'm doing a lot of the work on pack200, and it's a
really nice self-contained unit. If there were many others working on
it as well, and all I was doing was adding little bits here and there,
then yes, what you propose might be tenable. But I'm creating a fair
number of classes and new classes in doing this, and merging between
directories because of the current layout doesn't sound appealing.

> Any new files/folders you'd do an 'svn add' and anything that needs to
> be deleted you'd do an 'svn del'. Then run the Harmony builds to
> verify your working copy is as expected. Once you're set, run an 'svn
> diff'.

The problem is, I've done 'svn del', 'svn add' and even 'svn move'.
They do not show up in svn diff. The last couple of patches I've sent
have not been able to be applied because they refer to files that
aren't there, even though I've 'svn added' them to my local copy. It's
nigh on impossible to do new development using svn and contributing
patches like this, and to be honest, it's the main reason why I don't
do lots of small commits. I generally budget for a week or more of
downtime between when I've finished doing a chunk of work and filing a
patch to after all the problems have been ironed out, and I've had to
send in new patches or even complete zips of the files.

Try it. Check out SVN using an anonymous URL, make a change. Add a new
file. Do svn add. Do svn diff. Then try to apply that patch to another
freshly checked out file. That's exactly what I'm doing, and it just
doesn't work. SVN works fine for new development if you're a
committer, and for contributing small fixes by patching. But it's
really unsuitable for larger new pieces of work contributing as
patches all the time.

Alex.

Mime
View raw message