On 23/11/06, Nathan Beyer <[EMAIL PROTECTED]> 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.
