Create patch with relative paths

[Ivan Zuboff]

Hello!

Say I'm having a repo with the following structure: /a/1, where a is folder and 1 is file in this folder. If I edit file "1" and create a patch from the top of my repo, it will contain no relative path mentioning "a" folder":
Index: 1
===================================================================
--- 1    (revision 123)
+++ 1    (working copy)
// changes here

This causes guessing when applying the patch. Obviously guessing is not always working right in non-trivial repository. When I edit Makefile in some subfolder and do nothing else, my patch doesn't contain any clue about what Makefile exactly should be patched. Sadly, this is a long-standing problem for me and my collegues with TortoiseSVN.

If repo would also contain file /2 and I would edit it too, then patch would look different (like I would like to see it): I would get "a/1" instead of just "1" and guessing would work much better on applying.

Can I always create a patch with relative paths ("a/1" instead of "1") via TortoiseSVN? Is there any option that enables this behavior?

Thank you very much in advance.

Best regards, Ivan

[Ivan Zuboff]

Console command "svn diff" from the root of the repo shows patch/diff with long relative paths, contrary to TortoiseSVN from the root while creating patch or showing unified diff.

четверг, 28 июля 2022 г. в 13:05:25 UTC+3, Ivan Zuboff:

[Tony Rietwyk]

I don't have any problem creating a patch via TortoiseSVN / Create patch... on the root - it includes relative paths as expected.

[Ivan Zuboff]

Tony, thank you very much for your input! Indeed, right click on repository and pressing "Create patch" gives expected result.

I used another way to create a patch. In TortoiseSVN-1.14.3.29387 on Windows 10 I usually right-click on marked files in commit window and then click "Create patch". Patches created this way don't have relative paths inside, as I described above.

Resulting patch:

Index: BUILD-CC.txt
===================================================================
--- BUILD-CC.txt    (revision 244744)
+++ BUILD-CC.txt    (working copy)
*some changes here*

So, you sort of fixed my problem. With your help, I now know how to create "right" patches not only from command line, but also from GUI. Massive thanks!

But then my question can be phrased another way: is this expected and right behavior that creating patches from commit window work this weird way, different from "Create patch" button after right-click on the repo and different from svn diff on the command line?

пятница, 29 июля 2022 г. в 06:04:17 UTC+3, Tony Rietwyk:

[Ivan Zuboff]

But then my question can be phrased another way: is this expected and right behavior that creating patches from commit window work this weird way, different from "Create patch" button after right-click on the repo and different from svn diff on the command line?

(Sorry for repetion, I think I should put this question it in a separate email for visibility.)

пятница, 29 июля 2022 г. в 11:44:49 UTC+3, Ivan Zuboff:

[Daniel Sahlberg]

I saw this as well a while ago, discussed as part of another thread in tortoisesvn-dev https://groups.google.com/g/tortoisesvn-dev/c/aw32jamqpCw

TLDR; it would probably be a nice improvement to TortoiseProc to base the patches in the root of the working copy but no-one has looked at it since TortoiseMerge usually works out finding the correct file to patch. Anyone looking for a summer project would be welcome to fix this.

Kind regards,

Daniel

[Stefan]

Sorry, I'm a little late to this discussion. But here's my input:

As already discovered, creating a patch with the appropriate command creates a patch with relative paths from where the patch is created.

As a matter of fact, all "create patch/diff" commands always create the paths in the patch file relative to from where they're started, or when from a status control (like in the commit dialog) with the lowest common denominator as the root.

The point is that these are relative paths, so they're actually relative :)

I guess all of you in this discussion thread work in a team where everyone has checked out from the same 'root' of a repo (e.g. trunk). So you maybe expect those commands to always use the wc root as the root of the relative paths. But many teams don't work that way, especially those that have >100GB working copies if checked out from trunk - in such teams it happens that different team members have different subfolders checked out. So there the relative path is relative to their working copies. Now imagine person A has /trunk checked out because that person maybe also does a full build of the project. Person B has only /trunk/subProject1 checked out. Person A needs to send B a patch of some files in subProject1, so if TSVN would always create the patch with paths relative to the WC root, person B would get a patch that can't be applied because the paths would contain /subProject1/file1.cpp, and the WC might be named subProject1-test - so that part's wouldn't match.

In this case, person A can create the patch from subProject1 instead of the wc root and get a patch that person B can apply.

I hope my explanation on why this is done in TSVN like this wasn't too long....

Stefan

[Daniel Sahlberg]

I was under the impression that the svn command line client always based the diffs in the WC root, but I realise now that I was wrong.

In the example below, dev is just a regular directory and subversion_private is the wc root. As show by the example, the svn command line client adds the dev directory as well as the wc root directory (both which are irrelevant to the patch in relation to the repository). If the diff is done from the services subdirectory, it adds no path at all.

[[[

D:\>svn diff dev\subversion_private\
Index: dev/subversion_private/services/freenode-IRC.txt
===================================================================
--- dev/subversion_private/services/freenode-IRC.txt    (revision 107775)
+++ dev/subversion_private/services/freenode-IRC.txt    (working copy)

[...]

D:\Dev\subversion_private\services>svn diff
Index: freenode-IRC.txt
===================================================================
--- freenode-IRC.txt    (revision 107775)
+++ freenode-IRC.txt    (working copy)

]]]

I believe TortoiseSVN fares no worse than the svn command line client and I think the behaviour is quite reasonable. Especially the case made by Stefan with A and B makes sense.

I will retract my previous statement about always basing the patch in the WC root. Of course this could be added as a configurable behaviour in case it is important to someone, but personally I have more urgent itches to scratch.

Kind regards,

Daniel

[Ivan Zuboff]

Just to clarify. My point was that if I open commit window in WC root, I would like to see paths in patch based on WC root. If I open commit window in WC subfolder, I would like to see paths in patch based on this folder. To put it in another words, personally think that svn diff behavior is most reasonable and simultaneously fully flexible.

пт, 29 июл. 2022 г., 20:44 Daniel Sahlberg via TortoiseSVN <torto...@googlegroups.com>:

--
You received this message because you are subscribed to a topic in the Google Groups "TortoiseSVN" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tortoisesvn/F8N_bikqPaE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/166abd47-08d9-4b44-96cd-ec8513f0571dn%40googlegroups.com.

[Stefan]

On Friday, July 29, 2022 at 7:55:08 PM UTC+2 Ivan Zuboff wrote:

Just to clarify. My point was that if I open commit window in WC root, I would like to see paths in patch based on WC root. If I open commit window in WC subfolder, I would like to see paths in patch based on this folder. To put it in another words, personally think that svn diff behavior is most reasonable and simultaneously fully flexible.

I remember that this was done once, but then users complained that if they select only one file from the commit dialog they only want to have the filename in the patch, not the path of the whole wc up to that file (that guy didn't want to know others those paths to not reveal that information). Then others agreed and even wanted that to happen for multi-file selections to create a patch. So now it works like this.

Also, you can start a commit dialog by selecting multiple items in the wc, so a commit dialog does not have one root path per se, but can have multiple 'root' paths.

So, it seems it's just not possible to have it work like all people expect or want.

Sure, it would be possible to e.g. use the wc root iff:

* only one path is selected when starting the commit dialog

* multiple files are selected for creating the patch

but then I'm sure users will get confused on why it sometimes works this way and sometimes not, and they will come here to complain...

[Ivan Zuboff]

Stefan, thank tou very much for detailed explaination of this behavior!

пт, 29 июл. 2022 г., 21:04 Stefan via TortoiseSVN <torto...@googlegroups.com>:

--

You received this message because you are subscribed to a topic in the Google Groups "TortoiseSVN" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tortoisesvn/F8N_bikqPaE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tortoisesvn...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/bf481c5e-2139-4c72-8292-8909e0515c64n%40googlegroups.com.

[David Balažic]

On Friday, 29 July 2022 at 19:13:37 UTC+2 Stefan wrote:

> I guess all of you in this discussion thread work in a team where everyone has checked out from the same 'root' of a repo (e.g. trunk). So you maybe expect those commands to always use the wc root as the root of the relative paths. But many teams don't work that way, especially those that have >100GB working copies if checked out from trunk - in such teams it happens that different team members have different subfolders checked out. So there the relative path is relative to their working copies. Now imagine person A has /trunk checked out because that person maybe also does a full build of the project. Person B has only /trunk/subProject1 checked out. Person A needs to send B a patch of some files in subProject1, so if TSVN would always create the patch with paths relative to the WC root, person B would get a patch that can't be applied because the paths would contain /subProject1/file1.cpp, and the WC might be named subProject1-test - so that part's wouldn't match.
In this case, person A can create the patch from subProject1 instead of the wc root and get a patch that person B can apply.

To solve this, patching tools have an option like:

-pnum or --strip=num

Strip the smallest prefix containing num leading slashes from each file name found in the patch file. A sequence of one or more adjacent slashes is counted as a single slash. This controls how file names found in the patch file are treated, in case you keep your files in a different directory than the person who sent out the patch. For example, supposing the file name in the patch file was

Regards,

David

[Irene Irenebrug]

Hello,

I don't know how to correct post, errors.
But for years i have this issue when i do show changes.

It shows the code from 20474 with show changes. But it said '20476' (-1) in this case.
Is this normal behaviour or a bug??
 

[Ivan Zuboff]

Hello, Irene.

Unfortunately, I can't send this message directly to you because I don't know your email.

I suppose that you should create a new thread in this forum for your question instead of asking it in some existing thread. This way it is more likely that you will attract the attention of TortoiseSVN users and developers.

Thanks!

Best regards, Ivan

среда, 24 августа 2022 г. в 18:57:50 UTC+3, Irene Irenebrug:

[Stefan]

On Wednesday, August 24, 2022 at 5:57:50 PM UTC+2 Irene Irenebrug wrote:

It shows the code from 20474 with show changes. But it said '20476' (-1) in this case.
Is this normal behaviour or a bug??

this is normal behavior. You ask for a diff of what changed in a specific revision. So the diff is created for the revision and revision-1. There's no need to get a log and check what's the previous revision that file was changed like you expect here. The diff would not be different!