From: Philipp K. K. <pk...@sp...> - 2024-03-04 11:18:41
|
Do we still have the problem of the website updating from svn only when the size of files changes? I fixed a typo on our starting page 26 hours ago, and the website still has the typo. Philipp |
From: Erik P. <epe...@iv...> - 2024-03-05 06:15:45
|
On Mon, 2024-03-04 at 12:18 +0100, Philipp Klaus Krause wrote: > Do we still have the problem of the website updating from svn only > when > the size of files changes? > > I fixed a typo on our starting page 26 hours ago, and the website > still > has the typo. > > Philipp Yes, it updates using rsync with the --size-only parameter. If you want to change just a single character, remember to also add/remove a blank or newline somewhere inconspicuous so that the overall file size also changes. Erik |
From: Philipp K. K. <pk...@sp...> - 2024-03-05 09:21:30
|
Am 05.03.24 um 07:00 schrieb Erik Petrich: > Yes, it updates using rsync with the --size-only parameter. What is the reason for the --size-only? A normal rsync would trigger if times or sizes change. Does something not under our control change the times? Philipp |
From: Erik P. <epe...@iv...> - 2024-03-09 09:04:56
|
On Tue, 2024-03-05 at 10:21 +0100, Philipp Klaus Krause wrote: > Am 05.03.24 um 07:00 schrieb Erik Petrich: > > Yes, it updates using rsync with the --size-only parameter. > > What is the reason for the --size-only? A normal rsync would trigger > if > times or sizes change. Does something not under our control change > the > times? > > Philipp I looked into the history hoping to find a comment when the option was introduced, but the --size-only has been there since Borut's initial check-in of both files that I've seen it used. Looking further, it seems that the default timestamp on files created during the svn checkout reflect the time they were checked out, rather than the time they were last committed. In that case, rsync would be trying to update all the web site files every day since there was a fresh checkout from svn every day. I think we can change how the timestamps are set on checkout, but I need to read more of the svn documentation to understand this better first. Erik |
From: Sebastien L. <seb...@lo...> - 2024-03-11 15:21:53
|
Hello, Here it is in the svn book: https://svnbook.red-bean.com/en/1.5/svn-book.pdf page 221: use-commit-times Normally your working copy files have timestamps that reflect the last time they were touched by any process, whether your own editor or somesvnsubcommand. This is generally convenient for people developing software, because build systems often look at timestamps as a way of deciding which files need to be recompiled. In other situations, however, it's sometimes nice for the working copy files to have timestamps that reflect the last time they were changed in the repository. Thesvn ex- portcommand always places these “last-commit timestamps” on trees that it pro- duces. By setting this config variable toyes, thesvn checkout,svn update,svn switch, andsvn revertcommands will also set last-commit timestamps on files that they touch. Looks like this setting is to be defined in the subversion configuration file at $HOME/.subversion/config Alternatively svn export should be used instead of checkout/update. Best regards Sebastien Le 09/03/2024 à 10:04, Erik Petrich a écrit : > On Tue, 2024-03-05 at 10:21 +0100, Philipp Klaus Krause wrote: >> Am 05.03.24 um 07:00 schrieb Erik Petrich: >>> Yes, it updates using rsync with the --size-only parameter. >> What is the reason for the --size-only? A normal rsync would trigger >> if >> times or sizes change. Does something not under our control change >> the >> times? >> >> Philipp > I looked into the history hoping to find a comment when the option was > introduced, but the --size-only has been there since Borut's initial > check-in of both files that I've seen it used. > > Looking further, it seems that the default timestamp on files created > during the svn checkout reflect the time they were checked out, rather > than the time they were last committed. In that case, rsync would be > trying to update all the web site files every day since there was a > fresh checkout from svn every day. I think we can change how the > timestamps are set on checkout, but I need to read more of the svn > documentation to understand this better first. > > Erik > > > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Erik P. <epe...@iv...> - 2024-03-12 04:41:38
|
On Mon, 2024-03-11 at 16:04 +0100, Sebastien Lorquet wrote: > > Hello, > > Here it is in the svn book: > https://svnbook.red-bean.com/en/1.5/svn-book.pdf > > page 221: > > use-commit-times > Normally your working copy files have timestamps that reflect the > last time they were > touched by any process, whether your own editor or some svn > subcommand. This is > generally convenient for people developing software, because build > systems often look > at timestamps as a way of deciding which files need to be recompiled. > In other situations, however, it's sometimes nice for the working > copy files to have > timestamps that reflect the last time they were changed in the > repository. The svn ex- > port command always places these “last-commit timestamps” on trees > that it pro- > duces. By setting this config variable to yes, the svn checkout, svn > update, svn > switch, and svn revert commands will also set last-commit timestamps > on files that > they touch. > > Looks like this setting is to be defined in the subversion > configuration file at $HOME/.subversion/config > > Alternatively svn export should be used instead of checkout/update. > > Best regards > > Sebastien Thanks for tracking this down for me. My day job is keeping me quite busy lately, so this is helpful. I'll try to implement this in the snapshot generation / website update process this weekend. Erik > |