As can be seen from <https://bugs.webkit.org/show_bug.cgi?id=28387#c5> and <http://trac.webkit.org/changeset/47399>, bugzilla-tool will happily land patches in the wrong directory if they're not relative to the root of the SVN repository. We've worked with patches that are relative to a subdirectory for a long time now without trouble, so it would be great if bugzilla-tool didn't make a mess of the repository when it encounters one. If it can't deal with these patches, I'd be more than happy if it just refused to touch them rather than landing it anyway.
I totally agree! Just not sure what to do here. The tool which is doing the "wrong" thing here is actually svn-apply, which is happy to accept the patch which bugzilla-tool gives it and apply it. Some possible solutions I could think of: 1. svn-create-patch could be changed to add explicit information about directory adds. Right now svn-apply infers directory adds from file adds. 2. svn-apply (or bugzilla-tool) could be changed to try and match directory paths against known existing directory paths and fail when they look too similar. 3. svn-apply could be given a white-list of known top-level directories. All of these solutions would just be teaching svn-apply/bugzilla-tool to "fail" when it encounters these sorts of patches. I don't think that we should be making efforts to support patches from sub-directories. But I do think that we should have some minimal safe-guards in place to prevent sub-directory patches from causing havoc. I suggest we implement #3 above, as it's the simplest. I'm interested in your thoughts on the matter.
bugzilla-tool is all about moving more of our process out of our heads and into our scripts. :) So lots of little bugs like this are bound to crop up. I'm glad we're getting them down in bugs.webkit.org so that they can be squashed.
(In reply to comment #1) > I don't think that we should be making efforts to support patches from > sub-directories. But I do think that we should have some minimal safe-guards > in place to prevent sub-directory patches from causing havoc. It's something we've always supported in the past. As you said, the tool is about moving our process out of our heads, not reinventing the process.
Sure, but svn-create-patch is also the official process for creating a patch. And svn-create-patch was modified a while ago to always create patches with full paths. Re-stated: I think we should make the right thing (uploading patches with full paths, and landing them nicely) very very easy. And we should make the wrong thing (uploading patches with incomplete paths) hard, and bad things (landing patches with incomplete paths in the wrong places!) impossible. :) Again, I totally agree we should have guards in place to prevent patches with incomplete paths from turning into bad commits. I will implement solution 3.
This was fixed by bug 26999. *** This bug has been marked as a duplicate of bug 26999 ***