harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: Re: Re: [classlib][pack200] Status update (again)
Date Thu, 23 Nov 2006 15:46:56 GMT
On 11/22/06, Alex Blewitt <alex.blewitt@gmail.com> wrote:
> 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.

Why delete the files at all, just ignore them. Just create your own
Eclipse project files an point exclusively to the pack200 files. You
can do this many ways with Eclipse; create a project and use links to
pull in just the pack200 files, work within the 'archive' module and
add exclusion filters to remove all other files.

Have you considered just checking out the pack200 files alone? Create
your project folder, create source folder and then create
"org/apache/harmony/archive/internal" and then checkout
to 'pack200' under 'internal' and you're set.

> 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.

I know that deletes and moves can't be done via diffs, but adds can
and moves are just deletes and adds. In these cases I would just
suggest notification of files that need to be deleted in JIRA issues
and do everything ass updates and adds.

> 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.

I have tried this. I do this quite often in fact (here and elsewhere).
I've also committed patches that other people have created this way
and it works like a charm. Note, I do this all with the SVN command
line. I've been able to do this successfully with v1.3.2, v1.4.0 and
v1.4.2 SVN binaries for Windows.


> Alex.

View raw message