Fossil Forum

Determine if trunk updated
Login

Determine if trunk updated

Determine if trunk updated

(1) By curmudgeon on 2023-02-22 08:55:39 [link] [source]

If I run the command

   fossil update trunk

in a bash script what is the simplest way to determine if the trunk was changed?

(2) By mark on 2023-02-22 10:53:19 in reply to 1 [link] [source]

Something like:

#!/bin/sh

local checkout="$HOME/src/wt/fsl"

echo "changes:      None. Already up-to-date" > /tmp/stdout.expected
(cd $checkout && fossil update | tail -1 > /tmp/stdout)

cmp -s /tmp/stdout.expected /tmp/stdout
ret=$?
if [ $ret -ne 0 ]; then
	echo "trunk changed"
fi

http://yy.jamsek.net/xcb8

(3) By Warren Young (wyoung) on 2023-02-22 11:13:09 in reply to 1 [link] [source]

More reliable is to do it the other way around: find out if Fossil would update the checkout directory, then react based on the result:

#!/bin/sh
fossil sync
if [ -z "$(fossil changes --changed)" ]
then
    echo "No changes available."
elif fossil update --nosync      # already did the sync
then
    # now do whatever else you wanted to do if the tree changes
else
    # cope with update failure
fi

(4) By mark on 2023-02-22 11:39:28 in reply to 3 [link] [source]

That will give bogus results if in a checkout with local changes, causing the elif path even though the repository is already up-to-date:

22:36 ✔ ~/src/fsl » f sync
Sync with https://mark@fossil-scm.org/home
Round-trips: 1   Artifacts sent: 0  received: 0
Sync done, wire bytes sent: 1611  received: 217  remote: 45.33.6.223
22:36 ✔ ~/src/fsl » if [ -z $(f changes --changed) ]; then
> echo "no changes"
> elif f update --nosync
> then
> echo "unwanted rsync..."
> fi
-------------------------------------------------------------------------------
checkout:     86c4e6bf2683b9cf69a32ee2778a36065918467b 2023-02-22 00:09:14 UTC
tags:         trunk
comment:      Clarified one of the 2.21 changelog entries. (Started as fixing a typo.) (use
              r: wyoung)
changes:      None. Already up-to-date
unwanted rsync...

(5.1) By Warren Young (wyoung) on 2023-02-22 12:29:54 edited from 5.0 in reply to 4 [link] [source]

You're quibbling. I'm not trying to solve a specific yet vaguely-specified problem here, I'm giving a general solution: use the changes command instead of comparing human-readable output of commands against fixed strings. That's brittle. There is nothing that says it'll remain the same from one day to the next, much less one release to the next or one year to the next.

If the specific solution wants --updates instead of --changes, fine. That's a local detail.

(8) By mark on 2023-02-23 04:15:47 in reply to 5.1 [link] [source]

You're quibbling. I'm not trying to solve a specific yet vaguely-specified problem here, I'm giving a general solution:

That wasn't my intent, but to advise the OP of the unstated assumptions to preempt any unwanted results. As you mention, the problem statement was vague and without knowing what the condition guarded I thought it better to draw attention to that caveat.

comparing human-readable output of commands against fixed strings. That's brittle. There is nothing that says it'll remain the same from one day to the next, much less one release to the next or one year to the next.

Because on this—notwithstanding my very literal interpretation of the OP—I completely agree!

Although I do like mgagnon's solution. Incidentally, I have a script on one of my fossil servers that syncs the fossil repo hourly, and it checks for updates using manifest.uuid to trigger a build and update the local fossil binary.

(10) By Warren Young (wyoung) on 2023-02-23 06:49:45 in reply to 8 [link] [source]

it checks for updates using manifest.uuid to trigger a build

Yes, that's also good. It consumes a reliable data source that's highly unlikely to change in format and as easy to parse as you could wish. (if (old_hash != new_hash) {…)

(9.1) Originally by mark with edits by Warren Young (wyoung) on 2023-02-23 06:47:48 from 9.0 in reply to 5.1 [source]

Deleted

(6) By Martin Gagnon (mgagnon) on 2023-02-22 12:58:58 in reply to 1 [link] [source]

You can also compare the output of the whatis like this:

orig=$(fossil whatis current | grep artifact)
fossil update trunk
new=$(fossil whatis current | grep artifact)
if [[ "$orig" != "$new" ]]; then
    echo "Changed..."
else
    echo "Did not changed..."
fi

In fact, this will return "Changed..." if you were on a different branch before to update to trunk. You can always verify if your checkout was already in trunk by greping output of fossil whatis current or fossil info.

If you just want to check if trunk on remote change compared with your local repo trunk, (without considering on what is the version of your current checkout), you can simply do

orig=$(fossil whatis trunk | grep artifact)
fossil pull
new=$(fossil whatis trunk | grep artifact)
if [[ "$orig" != "$new" ]]; then
    echo "Changed..."
else
    echo "Did not changed..."
fi

It depend what you want exactly.

  • Note: You could have use fossil info | grep checkout instead of fossil whatis current | grep artifact, but it would not works on my second example.

(7) By curmudgeon on 2023-02-22 13:13:54 in reply to 1 [link] [source]

Thanks All. I should've said this was me updating the sqlite source code and I was already in the correct directory.

I was previously using "$(fossil update trunk)" and checking if it contained "Already up-to-date" using regex but always thought there must be a less ugly way of doing it. Warren's solution's what I want.

I'm having to rewrite code that was lost due to some bug in vs code and this is just reminding me of how much I destest bash.