Re: Patch file creation: Anchoring inconsistent

On 8/4/2016 11:31 AM, Daniel Hoenig wrote:
> Is there a specific reason for this?
>
> I can't think of any use case, from that perspective that former user request seems unreasonable: the fact that the CfM dialog can be spawned from any folder should make it aware of the path and not flatten all paths.
> And it makes the behavior of the two described ways to create a patch file inconsistent.
>
> Think of the scenario where you have a files that have the same name (which is actually the case when you use makefiles), they cannot not be distinguished in the patch file.
> I didn't try, but such a patch file would probably create an error in the attempt to apply it to a sandbox.
> The Crucible use case is definitly broken by that.
>
> Maybe an advanced settings switch could solve this for everybody?
>
I recall there were some discussions going on but I don't exactly recall
what the cases were about. Still, I can certainly think of use-cases
where the relative path would be preferred over the complete path. Just
to name two examples:
1. Assume you have a modification in a file which is being used in
different projects but in each project the file is located in a
different path. In this case just having the file name in the patch file
recorded will ensure that you can easily apply the patch onto different
projects regardless of differences in the project's tree structure.
2. Assume you just want to keep a backup of some current changes you
made on a file to apply it at a later point and don't want to bother
about an upcoming refactoring of the tree structure which is likely to
happen before you'd reapply the patch.

I'm not saying that the current behavior is my own preference. I'm just
saying that there are good arguments for both sides. Still I tend to
agree that the inconsistent behavior is suboptimal atm and adding a
setting to change the behavior sounds like a reasonable feature request.
If such a setting would be added, I'd however also like to suggest to
change the current behavior and restore consistency (one way or another)
and maybe have the setting control the behavior of both cases (rather
than only changing the behavior of one).

-- 
Regards,
Stefan Hett, Developer/Administrator
EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3181226
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].