On 23/11/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
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.
Yup, could do that. I'm not sure how the Subclipse client will deal with a mixture of svn- and non-svn-managed directories, and it's not like I've had much luck with that so far.
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 "https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200/"; to 'pack200' under 'internal' and you're set.
Yup, also could do that. But the recommended guidelines is to create a patch from the package root; and I couldn't do that if I was just checking out some of the sub-folders. It also doesn't solve the other problems; that the messages for the pack200 are separate from the other java.util.* implementation; how to have a separate MANIFEST.MF for the pack200 code so that it could be used in a separate OSGi bundle; or for that matter being able to run the build on just that component without having the java.* code in there as well. I'd like to try and get to a stage where I'm able to build the bundle successfully with build.xml rather than just checking for compile-time safety.
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.
So this is the problem -- in one of my recent refactorings, I moved a file from the parent package to a (new) subpackage. What's the workaround for these cases in the future? And how do I do an ass update? ;-)
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.
OK, well I'm on SVN 1.3.1 for Mac, but I think your point above regarding the delete/move is probably the wall I was running into repeatedly, especially as I've been doing renames too (do they survive the diff process, or are they just a move?) Heigh ho. Hopefully the full dump of the source tree will help out somewhat and once that's patched, we can start doing shuffling around. I'd still like to know what the problems are with (or arguments against) moving the pack200 stuff in its own separate module; after all, you don't get a JDBC driver and the JDBC APIs packaged into the same Jar; why should the Pack200 implementation be any different? Obviously the core Java classes (java.util.jar.pack200 etc.) would stay where they are, but the org.apache.harmony stuff could easily be pulled out into a separate module, thus making the build process simpler than checking out folders piecemeal whilst also decoupling the messages for the j.u.j and o.a.h.p2 classes and giving the o.a.h.p2 its own MANIFEST.MF. But perhaps I'm missing the big picture here ... can someone help educate me? Alex.
