On 23/11/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
Depends how you create the patch. I know using the command-line "svn diff" it only uses the relative path, but any time I've every done a diff with the Eclipse team tools (CVS, Subclipse) it puts an absolute path in the file every time. Modifying the paths in these files after diff creation is pretty safe -- usually one Find/Replace fixes everything.
Yeah, I ended up hand-editing the Indexes in the patch to remove the absolute path reference. However, even when I did that, I still had problems -- largely due to the refactoring that I'd done with moves.
> 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? If you do the refactor within Eclipse (Subclipse enabled), this should do the "adds" for you, so when the diff is created the new files should be in the patch. Then just list the files to be deleted in the JIRA with the patch. An easy way to get the list of deleted files would be run "svn status" and use the output from that; everything with a "D" is what needs to be deleted.
Yeah, I don't think the Adds are the problem. However, the code is in a stage where I'm refactoring quite a lot, and although intra-file refactorings aren't likely to be an issue, refactoring to move classes to different packages certainly sounds like a show-stopper. What about renaming a file? Doesn't that get treated as a move, too; in which case, even changing a name of a file is likely to cause problems :-(
Depending on how you perform the refactor, a move may not work well. For example, if you're move a whole folder full of files to a new folder, then this would be translated into an SVN copy of the folder and delete of the folder as this is the most optimized SVN command. In this case, I would suggest creating the new folders and then performing individual files copies, so they are treated as individual new file adds.
This isn't an option when performing a refactoring. As you probably know, when you do a refactor -> move in Eclipse, it does the updates for each of the individual files on your behalf. It's not a case of me choosing to create a directory, and then doing individual drag-and-drops. It seems to me that it's just not well suited for fluctuating work, and as I've previously observed, the amount of time and effort to create a patch (and for it to be successfully applied) is basically something which requires me to stop work for a week or so at a time whilst issues like this get resolved. I certainly can't end up doing new work, because whatever incoming changes end up obliterating any work I've done (when you've svn add'd a file and then someone else commits it, it shows up as a conflict on your local copy ... so doing any mods on it until it's committed is basically a no-no). I think patching is a great way of making the occasional change to existing code. I don't think it works well for new development. Alex.
