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)

Reply via email to