"create patch" for added files always includes parent folders

[GoogleCodeExporter]

reported on the mailing list:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=30687
52

Newly added to SVN file:

/one/two/three/three.txt
/one/two/two.1/two.1.txt.txt

I then select 'three.txt' but the selection also includes:

one
two
two/three
two/three/three.txt

This shows that having select 1 file for the patch, not only do I get 4
copies of that file in the patch, I also get a file that wasn't selected:

Original issue reported on code.google.com by tortoisesvn on 18 Nov 2013 at 6:09

[GoogleCodeExporter]

This issue was closed by revision r24961.

Original comment by tortoisesvn on 18 Nov 2013 at 7:19

• Changed state: Fixed

[GoogleCodeExporter]

This issue was closed by revision r24963.

Original comment by tortoisesvn on 18 Nov 2013 at 8:59

[GoogleCodeExporter]

This fix did seem to work but then I had further problems with 1.8.4
This morning I updated to the very latest TortoiseSVN 1.8.7, Build 25475 - 64 
Bit , 2014/05/05 20:52:12

And as you can see from the attached patch file, there is still something not 
right.
With each file appearing multiple times, tools like Atlassian's Crucible add 
each file multiple times to a review.

Original comment by paul.slo...@gmail.com on 27 May 2014 at 10:46

Attachments:

• issue-590.patch

[GoogleCodeExporter]

That's expected. What you see here is one diff window for every changed 
property. Since you changed/added multiple properties on every file, you get 
multiple diff windows.

Original comment by tortoisesvn on 27 May 2014 at 5:28

[GoogleCodeExporter]

That doesn't make sense.

So why does the same stuff appear more than once?

The following diff appears 3 times in the patch file - each time the same and 
each time showing all 3 properties changed:

Index: one/two/one-two.txt
===================================================================
--- one/two/one-two.txt (revision 0)
+++ one/two/one-two.txt (working copy)
@@ -0,0 +1 @@
+One Two file
\ No newline at end of file

Property changes on: one/two/one-two.txt
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:needs-lock
## -0,0 +1 ##
+*
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property

Also, if I get the patch without the property changes, it stillThat doesn't 
make sense.

So why does the same stuff appear more than once?

The following diff appears 3 times in the patch file - each time the same and 
each time showing all 3 properties changed:

Index: one/two/one-two.txt
===================================================================
--- one/two/one-two.txt (revision 0)
+++ one/two/one-two.txt (working copy)
@@ -0,0 +1 @@
+One Two file
\ No newline at end of file

Property changes on: one/two/one-two.txt
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:needs-lock
## -0,0 +1 ##
+*
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property

Also, if I get the patch without the property changes, it still has multiple 
diff sections for the same file!

Example - the following repeated 3 times verbatim:

Index: one/two/one-two.txt
===================================================================
--- one/two/one-two.txt (revision 0)
+++ one/two/one-two.txt (working copy)
@@ -0,0 +1 @@
+One Two file
\ No newline at end of file

Original comment by paul.slo...@gmail.com on 27 May 2014 at 6:09

Attachments:

• issue-590-2.patch

[GoogleCodeExporter]

BTW this problem is specific to NEW files added to SVN.

Original comment by paul.slo...@gmail.com on 27 May 2014 at 6:10

[GoogleCodeExporter]

Ah, now I remember:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201311.mbox/%3C528A6925.
10402@wandisco.com%3E

I've reported this to the svn dev list before, but it hasn't been fixed.

Maybe you should send an email there as well to remind them of this issue.

Original comment by tortoisesvn on 27 May 2014 at 6:39