harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: Re: Re: Re: [classlib][pack200] Status update (again)
Date Fri, 24 Nov 2006 09:20:28 GMT
On 23/11/06, Nathan Beyer <nbeyer@gmail.com> 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.

Mime
View raw message