I destroyed my subversion tree. (I attempted to ignore a few files, broke something, and now the svn says it can't find my root directory, even though it correctly notes the differences between files in said directory.) So, now I have about twenty files from my current project that I'd like to commit but can't.
I ended up checking out a new tree entirely, but now I don't know how to intelligently merge my files from the broken tree to the new tree I just checked out. I don't want to simply copy the files, as this will wipe changes others have done since I've updated. (The broken tree doesn't let me update.) Using 'svn merge' isn't meant to be used on two local copies, right? What tools can I use?
Use kdiff3 and manually merge your changes into the repository. Then commit.
I don't think that you can find better merging tool than winmerge
BTW - I didn't like the kdiff3 :)
Related
One of our teams recently migrated a good deal of legacy data to a folder with all of the current data. Some of the team members weren't aware of the changes, so they continued to make modifications in the legacy folder.
I'd like to consolidate the data by doing timestamp checks. I can write a script for this, but I essentially want to do a windows explorer merge of two folders, where the option selected is always the "newer" one in conflicts. That is, if the source has the newer file, copy the source into the dest. If the dest is newer, don't copy the source into the dest. If the source exists but the dest doesn't, copy the source over.
I'm writing a quick script in Java, but I'm running into some issues, and I wanted to know if there's a much simpler solution to simply always select the "newer" option.
To copy file Standard concise way to copy a file in Java?
To get timestamp http://docs.oracle.com/javase/6/docs/api/java/io/File.html#lastModified%28%29
I'm currently using Java and I'm looking for a program that saves a new version of what I'm doing each time I compile. I don't mind if it doesn't run, I can go in and edit the class name to make it match the .java name afterwards. As I'm a beginner, I keep getting caught by overextending myself and then breaking the project I'm working on irreparably. I'm just looking for a way to go back to a safe state.
I'm sure their are programs for this, but because I don't know the collective noun for them, finding one is next to impossible.
All help is much appreciated.
What you're looking for is revision control. This works independent of the language you're dealing with, since all the VCS is concerned with is the state of the software at a particular snapshot in time.
Some recommendations:
Subversion
Git
Mercurial
IntelliJ IDEA also comes with a built-in local revision system, which allows you to visit a particular file's history. It'd still be preferable to use either Git or Subversion.
There are also sites that you can host your project on to better preserve your project, such as Github or Google Code. Github uses...Git, but Google Code will allow you to use a few others, such as Subversion and Mercurial.
Use a Dropbox folder. If you use Eclipse, just put the entire folder in the Dropbox folder, and you are set to go with a backup-ed IDE.
Added bonus: access your project from anywhere.
You could also use GitHub, but then your source code will be open to the community unless you pay for one of their "plans".
Also, consider using Bitbucket, which isn't known as well, but is free. (Thanks to A--C for that alternative to GitHub)
I was working on the project in eclipse in which I have added this maven dependency for PDFBOX
Maven dependency
<dependency>
<groupId>org.apache.pdfbox</groupId>
<artifactId>pdfbox</artifactId>
<version>1.6.0</version>
</dependency>
And I was getting the error on some pdf file as:
Parsing Error, Skipping Object
java.io.IOException: expected='endstream' actual='' org.apache.pdfbox.io.PushBackInputStream#1b8d77fe
at org.apache.pdfbox.pdfparser.BaseParser.parseCOSStream(BaseParser.java:439)
at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:552)
at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:184)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1088)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1053)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:74)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:197)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:197)
at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:135)
at org.apache.tika.Tika.parseToString(Tika.java:357)
at edu.uci.ics.crawler4j.crawler.BinaryParser.parse(BinaryParser.java:37)
at edu.uci.ics.crawler4j.crawler.WebCrawler.handleBinary(WebCrawler.java:223)
at edu.uci.ics.crawler4j.crawler.WebCrawler.processPage(WebCrawler.java:460)
at edu.uci.ics.crawler4j.crawler.WebCrawler.run(WebCrawler.java:129)
at java.lang.Thread.run(Thread.java:662)
So when I google it, I found there was some bug in BaseParser.java file, So they have given the patch(https://issues.apache.org/jira/browse/PDFBOX-195) for this java file only.. So my question is how can I modify this java file only.. I can see the BaseParser.class file in eclipse as I have attached the source doc for that PDFBOX-Issue. Any suggestions will be appreciated.
Given that BaseParser.java is an Apache file, there is absolutely no reason why you cannot download the source, make your changes and re-compile it. I have done this with Apache code in the past. It was pretty straight forward and took me only a few minutes. Remember to submit your fix back to Apache so that way it will be included in the release.
You can:
create subclass manual (and use it if it possible)
download source, fix it, recompile, and finally, overwrite it in jar
create subclass programmaticly (using cglib or asm)
download only BasicParser, mock all depends (just create empty class files with needs methods), recompile it and put in jar (or ./ext ./endorsed dir in jvm, if you want)
Generally, one doesn't modify a class file directly, they download the source code and then rebuild the class file with javac. Yes, it is possible to modify class files without doing such a thing; but, patch files are not generally binary patch files, they are generally source code patch files.
Stefanglase has mentioned that the release you are working with should have the patch applied, but there is a small chance that a recent change reintroduced the issue. You might want to verify that you're not solving the wrong problem before you get too deep into it.
On the rare odds that you really want to modify a binary, you open it with a hexadecimal editor, or a hexeditor for short. Basically this allows you to set any byte in the file to any value, which means you must have a strong knowledge of the file's internal format, what is allowed / disallowed, and how to make allowable changes that actually implement your expected behavior. In short, you'll be doing a compiler's work manually, by hand.
It can be done, but it is the sort of task that generally requires a lot of knowledge, and few people have that knowledge already, so the costs of learning that knowledge and successfully implementing the change is likely much higher than rebuilding from available patched source. Even the costs of successfully implementing the change with the knowledge of the general principals and techniques already present isn't something that one can say with certainty is less than the costs of rebuilding the entire library with patched source.
Good Luck.
I'm trying to create a process to patch our current java application so users only need to download the diffs rather than the entire application. I don't think I need to go as low level as a binary diff since most of the jar files are small, so replacing an entire jar file wouldn't be that big of a deal (maybe 5MB at most).
Are there standard tools for determining which files changed and generating a patch for them? I've seen tools like xdelta and vpatch, but I think they work at a binary level.
I basically want to figure out - which files need to be added, replaced or removed. When I run the patch, it will check the current version of the software (from a registry setting) and ensure the patch is for the correct version. If it is, it will then make the necessary changes. It doesn't sound like this would be too difficult to implement on my own, but I was wondering if other people had already done this. I'm using NSIS as my installer if that makes any difference.
Thanks,
Jeff
Be careful when doing this--I recommend not doing it at all.
The biggest problem is public static variables. They are actually compiled into the target, not referenced. This means that even if a java file doesn't change, the class must be recompiled or you will still refer to the old value.
You also want to be very careful of changing method signatures--you will get some very subtle bugs if you change a method signature and do not recompile all files that call that method--even if the calling java files don't actually need to change (for instance, change a parameter from an int to a long).
If you decide to go down this path, be ready for some really hard to debug errors (generally no traces or significant indications, just strange behavior like the number received not matching the one sent) on customer site that you cannot duplicate and a lot of pissed off customers.
Edit (too long for comment):
A binary diff of the class files might work but I'd assume that some kind of version number or date gets compiled in and that they'd change a little every compile for no reason but that could be easily tested.
You could take on some strict development practices of not using public final statics (make them private) and not every changing method signatures (deprecate instead) but I'm not convinced that I know all the possible problems, I just know the ones we encountered.
Also binary diffs of the Jar files would be useless, you'd have to diff the classes and re-integrate them into the jars (doesn't sound easy to track)
Can you package your resources separately then minimize your code a bit? Pull out strings (Good for i18n)--I guess I'm just wondering if you could trim the class files enough to always do a full build/ship.
On the other hand, Sun seems to do an okay job of making class files that are completely compatible with the previous JRE release, so they must have guidelines somewhere.
You may want to see if Java WebStart can help you as it is designed to do exactly those things you want to do.
I know that the documentation describes how to create and do incremental updates, but we deploy the whole application as it changes very rarely. It is then an issue of updating the JNLP when ready.
How is it deployed?
On a local network I just leave everything as .class files in a folder. The startup script uses robocopy or rsync to copy from network share to local. If any .class file is different it is synced down. If not, it doesn't sync.
For non-local network I created my own updater. It downloads a text file of md5sums and compares to local files. If different it pulls file down from http.
A long time ago the way we solved this was to used Classpath and jar files. Our application was built in a Jar file, and it had a launcher Jar file. The launcher classpath had a patch.jar that was read into the classpath before the main application.jar. This meant that we could update the patch.jar to supersede any classes in the main application.
However, this was a long time ago. You may be better using something like the Java Web Start type of approach, which offers more seamless application updating.
I'm looking for a tool that will give me a high level view of which files are different between two fairly large Java packages. If I could then drill down into individual files then that would be good. I don't want to go file by file if possible.. any ideas?
thanks
Beyond compare (and other diff tools) can do directory compares too ...
If you're more interested in API differences than content differences, check out JDiff.
For example the Google Guava project uses it to show changes between releases. Here is the r06 release diff: http://guava-libraries.googlecode.com/svn/tags/release06/javadoc/jdiff/changes.html
WinMerge is an excellent Windows standalone diff tool and I use it for almost all of my source files. It can navigate through folder structures (in your case, your Java packages).
If you do use version control, it integrates very well with TortoiseSVN (and perhaps others in the Tortoise family).
You can use pkgdiff tool to compare java archives:
pkgdiff A.jar B.jar
See sample report for args4j.
See also japi-compliance-checker for analysis of API changes in your java archives.
I use Kompare on Linux. Just a diff GUI front end, that can diff directories recursively. I believe there are many others (I'm sure I've seen a list somewhere).
Eclipse works well. Just select the two different packages (hold the Ctrl key, click on a package, click again on the other package), right click on one of the selected packages, go to the 'Compare With...' submenu, select 'Compare With Each Other'.
I have used Araxis Merge to do this too. It is also helpful for doing code merges. It is not free (about 80 bucks I think) but well worth it.
I always use eclipses team synchronize (for included cvs; this requires one revision checked in and another one disk) works same way with subclipse plugin for subversion.
If you are on windows and don't have the checked in a version control system you could use winmerge
Last I checked kdiff3 worked both on *nix and windows.