On Thu, Sep 02, 2010 at 11:14:27AM +0300, Daniel Shahaf wrote: > (Thanks for the examples. I suppose next time I should try to run > 'touch foo; $svn add foo; $svn diff --git' myself...) > > Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:05:41 +0200: > > On Wed, Sep 01, 2010 at 10:54:08PM +0300, Daniel Shahaf wrote: > > > Daniel Näslund wrote on Wed, Sep 01, 2010 at 11:28:51 +0200: > > > > (This started out as me trying to apply added paths using the > > > > information > > > > from a patch file in the git diff format. The only that I could come up > > > > with where an add could not be detected by just looking at the regular > > > > unidiff headers was adding an empty file (it has no unidiff headers). > > > > If anyone has any other cases, please let me know.) > > > > > > > > > > How does a diff adding an empty file look? > > > > Like this: > > > > Index: empty > > =================================================================== > > diff --git a/trunk/empty b/trunk/empty > > new file mode 10644 > > > > So, it boils down to having to recognize /^new file mode/ (even though > there are no following /^(---|+++)/ lines), right? > > I've never been inside the patch code, I don't know how easy/tricky it > would be to add this.
See svn_diff_parse_next_patch() for the gory details. > > Note that we allow empty files to be created for regular diffs too if > > they have property changes. This patch will create an empty file with > > property 'foo' set on it: > > > > Index: empty > > =================================================================== > > > > Property changes on: empty > > ___________________________________________________________________ > > Added: foo > > ## -0,0 +1 ## > > +value > > So this implicitly creates the file if it doesn't exist already; in > other words, we do not distinguish setting a property on an existing > file (without content changes) from adding a file with properties. > Would it be better to make a distinction --- for example, by generating > a /^new file/ line in the latter case? (that would be explicit and more > friendly to non-property-aware tools) My personal opinion is that it would be better to add a --git option to svn patch and only apply tree changes and property changes if we have a git diff and a the --git diff option given. Then we wouln't have these kind of overlapping cases. But for the user it's more convinient to just call 'svn patch PATCH_FILE' on whatever file we have at hand. It's a personal opinion and I'm not really advocating it... Just making noise I guess. :) Daniel (Näslund)