[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Do we want 'svn patch' to be able to add empty files?

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Wed, 01 Sep 2010 18:37:08 +0100

Daniel Näslund wrote:
> Hi!
>
> (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.)
>
> The question is: Do we want 'svn patch to be able to add empty files.
>
> + It's consistent with the idea of a git diff dealing with tree changes.
> - It adds an extra special case to the code. I've seen GNU patch with
> its gigantic if-spaghetti's. Just don't want to obscure the code with
> something that's not needed.
> - There might not be a use case for it, though I think I've heard of the
> use of empty files as markers. Just can't come up with an example
> right now.

If "add an empty file" is a well defined operation in Git-diff syntax,
then yes, it would be good to support it. As well as "delete this empty
file" and any other valid Subversion operations that aren't yet
supported.

This may be off topic, but I'm wondering whether Git has defined such
operations on directories fully or at all, since it doesn't version them
explicitly. I mean, can you tell the difference between "add empty file
A" and "add empty dir A"? I could go and look, but haven't time today.
If yes, great; if it doesn't, we'll have to invent syntax extensions to
do it. (I'm recalling that the goal of this work is we want Subversion
diffs to be able to support all valid Subversion changes, and we chose
Git format as a basis for supporting that. We don't want to constrain
ourselves to only the operations that Git supports.)

- Julian
Received on 2010-09-01 19:37:53 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.