I think the fix to svn_apply_autoprops.py should be something like below
(/subversion/trunk/contrib/client-side/svn_apply_autoprops.py)
If anyone with commit rights wants to fix it on the repo, feel free to use the
below, or improve it as necessary (my python knowledge is non-existing)
Index: sv
I notice that if I do a svn co on a project all files will get a
timestamp as of the co time.
But if I do a svn export of the same project the files retain their
original timestamps (the time of commit of the file).
Is there some argument that can be applied to svn co to tell it to
keep the timesta
On Wed, Jan 10, 2018 at 1:02 PM, Bo Berglund wrote:
> I notice that if I do a svn co on a project all files will get a
> timestamp as of the co time.
> But if I do a svn export of the same project the files retain their
> original timestamps (the time of commit of the file).
> Is there some argume
On Wed, 10 Jan 2018 13:08:14 +0100, Johan Corveleyn
wrote:
>On Wed, Jan 10, 2018 at 1:02 PM, Bo Berglund wrote:
>> Is there some argument that can be applied to svn co to tell it to
>> keep the timestamps?
>
>There is a client-side configuration option for that: use-commit-times=true.
>See the "
On Mon, Jan 8, 2018 at 2:24 PM, Max Bernhardt wrote:
> Hi all,
>
> We've just upgraded our subversion server from 1.4.6 to 1.9.7 and now I'm
> getting a strange merge conflict, when I'm trying to do a reverse merge on a
> baseline (trunk).
>
> The situation is as follows:
> /project/branches/i
Chris wrote on Wed, 10 Jan 2018 08:26 +:
> I think the fix to svn_apply_autoprops.py should be something like below
> (/subversion/trunk/contrib/client-side/svn_apply_autoprops.py)
> If anyone with commit rights wants to fix it on the repo, feel free to
> use the below, or improve it as neces