Re: [fossil-users] Quiet mode for update and sync
Is there any hope this is going to make it into trunk?
I think -hush is the best name for the flag (because it's not *quiet*,
it's *quieter*), and I don't see any need for a short form, it's
really only for use in scipts where typing 3 extra characters
shouldn't be an issue.
../Dave
On 7 October 2014 09:22, David Mason dma...@ryerson.ca wrote:
On 7 October 2014 02:30, Andy Bradford
amb-sendok-1415255446.lmkmojimnoldkcbjb...@bradfords.org wrote:
fossil sync /dev/null fossil update -n | grep '^changes:.*files
modified\.' {
fossil update 21 | mail -s 'Fossil update' m...@he.re
}
Best yet, although you actually want a -q switch on grep so you don't
get that line mailed to you.
fossil sync /dev/null fossil update -n | grep -q
'^changes:.*files modified\.' {
Or if you're running from cron, and cron is correctly figured, the mail
command is superfluous:
The mail command is because I actually want to send the mail to several
people.
But Stephan's concern about the extra work of running update twice led
me to the enclosed patch which adds a -m switch (and fixes a typo in
the help doc). It's a few more lines of code, but it's really just
formatting. So you would use this like:
fossil sync /dev/null fossil update -m | mail -s fossil
update m...@he.re ot...@the.re
I don't know about the switch name, but otherwise this seems like a
useful and trivial patch. -h|--hush was another possibility that I
actually like better, but some people think -h always means help.
Just --hush without a short form might be the best choice.
Thanks ../Dave
: ~/fs/fossil ; ./fossil diff --from trunk --to update-mail
Index: src/update.c
==
--- src/update.c
+++ src/update.c
@@ -83,22 +83,28 @@
** If FILES is omitted, all files in the current checkout are subject
** to being updated and the version of the current checkout is changed
** to VERSION. Any uncommitted changes are retained and applied to the
** new checkout.
**
+** The -m or --mail-quiet option suppresses status info unless there was
+** some change that took place in the current checkout. This is useful
+** in a cron script to send mail only when an update is performed, such as:
+** fossil update -m | mail -E -s update occurred a...@ex.com
b...@ex.com
+**
** The -n or --dry-run option causes this command to do a dry run.
** It prints out what would have happened but does not actually make
** any changes to the current checkout or the repository.
**
** The -v or --verbose option prints status information about
-** unchanged files in addition to those file that actually do change.
+** unchanged files in addition to those files that actually do change.
**
** Options:
** --case-sensitive BOOL override case-sensitive setting
** --debug print debug information on stdout
** --latest acceptable in place of VERSION, update to latest
version
** --force-missing force update if missing content after sync
+** -m|--mail-quiet quiet unless there are actual changes
** -n|--dry-run If given, display instead of run actions
** -v|--verbose print status information about all files
** -W|--width num Width of lines (default is to auto-detect). Must be 20
**or 0 (= no limit, resulting in a single line per
entry).
**
@@ -112,10 +118,11 @@
int dryRunFlag; /* -n or --dry-run. Do a dry run */
int verboseFlag; /* -v or --verbose. Output extra information */
int forceMissingFlag; /* --force-missing. Continue if missing content */
int debugFlag;/* --debug option */
int setmtimeFlag; /* --setmtime. Set mtimes on files */
+ int hideInfoFlag; /* -m or --mail-quiet. Quiet unless there are
actual changes */
int nChng;/* Number of file renames */
int *aChng; /* Array of file renames */
int i;/* Loop counter */
int nConflict = 0;/* Number of merge conflicts */
int nOverwrite = 0; /* Number of unmanaged files overwritten */
@@ -144,10 +151,11 @@
}
verboseFlag = find_option(verbose,v,0)!=0;
forceMissingFlag = find_option(force-missing,0,0)!=0;
debugFlag = find_option(debug,0,0)!=0;
setmtimeFlag = find_option(setmtime,0,0)!=0;
+ hideInfoFlag = find_option(mail-quiet,m,0)!=0;
/* We should be done with options.. */
verify_all_options();
db_must_be_within_tree();
@@ -514,15 +522,18 @@
free(zFullPath);
free(zFullNewPath);
}
db_finalize(q);
db_finalize(mtimeXfer);
- fossil_print(%.79c\n,'-');
if( nUpdate==0 ){
-show_common_info(tid, checkout:, 1, 0);
-fossil_print(%-13s None. Already up-to-date\n, changes:);
+if ( !hideInfoFlag ){
+ fossil_print(%.79c\n,'-');
+ show_common_info(tid, checkout:, 1, 0);
+ fossil_print(%-13s None. Already up-to-date\n, changes:);
+}
Re: [fossil-users] Quiet mode for update and sync
Thus said David Mason on Thu, 02 Oct 2014 09:35:50 -0400:
I want a script to run every 5 minutes and if there is any update,
email me the update log. But I don't want email every 5 minutes that
just says everything is up to date.
After thinking about it a bit more, I realized all we're doing here is
checking if fossil update --dry-run reports that there are changes,
right? So what about running this every 5 minutes?
fossil sync /dev/null fossil update -n | grep '^changes:' | grep -v 'None.
Already up-to-date' {
fossil update 21 | mail -s 'Fossil update' m...@he.re
}
Thanks,
Andy
--
TAI64 timestamp: 40005433869f
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said Andy Bradford on 07 Oct 2014 00:21:48 -0600:
fossil sync /dev/null fossil update -n | grep '^changes:' | grep -v
'None. Already up-to-date' {
fossil update 21 | mail -s 'Fossil update' m...@he.re
}
Perhaps something that matches a positive would be better:
fossil sync /dev/null fossil update -n | grep '^changes:.*files modified\.'
{
fossil update 21 | mail -s 'Fossil update' m...@he.re
}
Or if you're running from cron, and cron is correctly figured, the mail
command is superfluous:
fossil sync /dev/null fossil update -n | grep '^changes:.*files modified\.'
fossil update 21
Andy
--
TAI64 timestamp: 4000543388b9
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On 7 October 2014 02:30, Andy Bradford
amb-sendok-1415255446.lmkmojimnoldkcbjb...@bradfords.org wrote:
fossil sync /dev/null fossil update -n | grep '^changes:.*files
modified\.' {
fossil update 21 | mail -s 'Fossil update' m...@he.re
}
Best yet, although you actually want a -q switch on grep so you don't
get that line mailed to you.
fossil sync /dev/null fossil update -n | grep -q
'^changes:.*files modified\.' {
Or if you're running from cron, and cron is correctly figured, the mail
command is superfluous:
The mail command is because I actually want to send the mail to several people.
But Stephan's concern about the extra work of running update twice led
me to the enclosed patch which adds a -m switch (and fixes a typo in
the help doc). It's a few more lines of code, but it's really just
formatting. So you would use this like:
fossil sync /dev/null fossil update -m | mail -s fossil
update m...@he.re ot...@the.re
I don't know about the switch name, but otherwise this seems like a
useful and trivial patch. -h|--hush was another possibility that I
actually like better, but some people think -h always means help.
Just --hush without a short form might be the best choice.
Thanks ../Dave
: ~/fs/fossil ; ./fossil diff --from trunk --to update-mail
Index: src/update.c
==
--- src/update.c
+++ src/update.c
@@ -83,22 +83,28 @@
** If FILES is omitted, all files in the current checkout are subject
** to being updated and the version of the current checkout is changed
** to VERSION. Any uncommitted changes are retained and applied to the
** new checkout.
**
+** The -m or --mail-quiet option suppresses status info unless there was
+** some change that took place in the current checkout. This is useful
+** in a cron script to send mail only when an update is performed, such as:
+** fossil update -m | mail -E -s update occurred a...@ex.com b...@ex.com
+**
** The -n or --dry-run option causes this command to do a dry run.
** It prints out what would have happened but does not actually make
** any changes to the current checkout or the repository.
**
** The -v or --verbose option prints status information about
-** unchanged files in addition to those file that actually do change.
+** unchanged files in addition to those files that actually do change.
**
** Options:
** --case-sensitive BOOL override case-sensitive setting
** --debug print debug information on stdout
** --latest acceptable in place of VERSION, update to latest version
** --force-missing force update if missing content after sync
+** -m|--mail-quiet quiet unless there are actual changes
** -n|--dry-run If given, display instead of run actions
** -v|--verbose print status information about all files
** -W|--width num Width of lines (default is to auto-detect). Must be 20
**or 0 (= no limit, resulting in a single line per entry).
**
@@ -112,10 +118,11 @@
int dryRunFlag; /* -n or --dry-run. Do a dry run */
int verboseFlag; /* -v or --verbose. Output extra information */
int forceMissingFlag; /* --force-missing. Continue if missing content */
int debugFlag;/* --debug option */
int setmtimeFlag; /* --setmtime. Set mtimes on files */
+ int hideInfoFlag; /* -m or --mail-quiet. Quiet unless there are
actual changes */
int nChng;/* Number of file renames */
int *aChng; /* Array of file renames */
int i;/* Loop counter */
int nConflict = 0;/* Number of merge conflicts */
int nOverwrite = 0; /* Number of unmanaged files overwritten */
@@ -144,10 +151,11 @@
}
verboseFlag = find_option(verbose,v,0)!=0;
forceMissingFlag = find_option(force-missing,0,0)!=0;
debugFlag = find_option(debug,0,0)!=0;
setmtimeFlag = find_option(setmtime,0,0)!=0;
+ hideInfoFlag = find_option(mail-quiet,m,0)!=0;
/* We should be done with options.. */
verify_all_options();
db_must_be_within_tree();
@@ -514,15 +522,18 @@
free(zFullPath);
free(zFullNewPath);
}
db_finalize(q);
db_finalize(mtimeXfer);
- fossil_print(%.79c\n,'-');
if( nUpdate==0 ){
-show_common_info(tid, checkout:, 1, 0);
-fossil_print(%-13s None. Already up-to-date\n, changes:);
+if ( !hideInfoFlag ){
+ fossil_print(%.79c\n,'-');
+ show_common_info(tid, checkout:, 1, 0);
+ fossil_print(%-13s None. Already up-to-date\n, changes:);
+}
}else{
+fossil_print(%.79c\n,'-');
show_common_info(tid, updated-to:, 1, 0);
fossil_print(%-13s %d file%s modified.\n, changes:,
nUpdate, nUpdate1 ? s : );
}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said David Mason on Sun, 05 Oct 2014 11:05:27 -0400: + if ( statusFlag ) fossil_exit(nUpdate==0); } Before you start using this in your own fork, you might want to consider if having the update_cmd() function exit at this point will cause problems if FOSSIL_ENABLE_TH1_HOOKS is enabled when using statusFlag and there are no updates. I don't use FOSSIL_ENABLE_TH1_HOOKS (and maybe you don't either), but one side effect of causing update_cmd() to exit here means that FOSSIL_ENABLE_TH1_HOOKS code in main.c will not execute. Not sure if that is an issue. Someone who knows more about the #ifdef FOSSIL_ENABLE_TH1_HOOKS in main.c will likely know more: http://www.fossil-scm.org/index.html/info/394258fc8108f16ca99a8bac1a04fab209d53e7d?ln=757,765 I would look at other fossil subcommands to see if any of them exit (except those that call fossil_fatal co. or exit with an error); my cursory glance seems to indicate that most fossil subcommands do not exit except for errors. I suppose perhaps the current intention is to have it exit with with a non-zero (aka error) exit status if nUpdate==0 so perhaps this is not such a bad change, but it does warrant some consideration for the case where it will exit without an error. At the moment, nUpdate==0 will always cause fossil to exit non-zero because it doesn't actually sync, so nUpdate would only ever be 0 if you gave it a name to which Fossil can actually update, but it wouldn't mean that you have new sync content, only that there are changes possible from your current checkout to the new checkout requested. Thanks, Andy -- TAI64 timestamp: 4000543239e2 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On Sun, Oct 5, 2014 at 11:05 AM, David Mason dma...@ryerson.ca wrote: (I do updates via ssh) If you are only doing updates via ssh, why run a cron job every 5 minutes? You could make a wrapper script for Fossil that runs Fossil to perform the sync, then backgrounds itself so the ssh session can disconnect and update the published area and send the email. If you are concerned about multiple near simultaneous updates, then when the script backgrounds, it could create a sentinel file in a specific directory, wait 5 mins then check for other sentinels. If there are, it removes the sentinel file and quits. If not, it updates the published area, sends the email then removes the sentinel file and quits. This isn't perfect, but it reduces your processing to only when repo content is needed. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On 3 October 2014 14:04, Andy Bradford
amb-sendok-1414951486.goflecofghbmjnaaa...@bradfords.org wrote:
Are you simply looking for a way to be notified via email when there are
changes that have been updated into your working checkout?
Yes. I want an email when a change happens, but not an empty email
every 5 minutes (from each of the half dozen fossils I want up-to-date
on the server).
If so, I think the above script could be substituted for ``fossil update
-q'':
shouldiupdate.sh fossil update 21 | mail -s 'Fossil update' m...@he.re
Absolutely. It should work fine and it's better than my original
shell-only version. I don't really want to do it that way for a
couple of reasons: 1) I don't want to *have* to be running a fossil
server (I do updates via ssh); and 2) it seems like a lot of overhead
(execution as well as old version files) and redundancy.
In the interests of getting into the code a bit, I looked at
implementing this. Making it truly a quiet option was going to
require fairly major surgery, but after a bit of thought, I realized
that all I really needed was the exit status. I thought of making
update always exit with this status (a 1-line change), but I was
worried about legacy issues so I added that with a switch (patch
attached - 1 line of code beyond declaring and parsing the switch).
So instead of ``fossil update -q I would write ``fossil update -s -n
/dev/null. I think this is better as it's more incremental and also
more orthogonal.
I'd love for this (or something like it - if someone has a better name
for the switch, or wants to implement a real -q, or wants to make
update always exit with this status) to be part of fossil, as I don't
really want to maintain a fork.
Thanks, ../Dave
: ~/fs/fossil ; fs diff --from trunk
Index: src/update.c
==
--- src/update.c
+++ src/update.c
@@ -86,10 +86,16 @@
** new checkout.
**
** The -n or --dry-run option causes this command to do a dry run.
** It prints out what would have happened but does not actually make
** any changes to the current checkout or the repository.
+**
+** The -s or --status option causes this command to produce a false
+** exit status if no work was done (or would be done in the case of
+** a dry run). This exit status is testable in a shell. Does not
+** otherwise affect the operation of the command. Typically used with
+** the -n or --dry-run option.
**
** The -v or --verbose option prints status information about
** unchanged files in addition to those file that actually do change.
**
** Options:
@@ -96,10 +102,11 @@
** --case-sensitive BOOL override case-sensitive setting
** --debug print debug information on stdout
** --latest acceptable in place of VERSION, update to latest version
** --force-missing force update if missing content after sync
** -n|--dry-run If given, display instead of run actions
+** -s|--status Exits with false status if no work (would be) done
** -v|--verbose print status information about all files
** -W|--width num Width of lines (default is to auto-detect). Must be 20
**or 0 (= no limit, resulting in a single line per entry).
**
** See also: revert
@@ -108,10 +115,11 @@
int vid; /* Current version */
int tid=0;/* Target version - version we are changing to */
Stmt q;
int latestFlag; /* --latest. Pick the latest version if true */
int dryRunFlag; /* -n or --dry-run. Do a dry run */
+ int statusFlag; /* -s or --status. Produces false exit
status if no work (would be) done */
int verboseFlag; /* -v or --verbose. Output extra information */
int forceMissingFlag; /* --force-missing. Continue if missing content */
int debugFlag;/* --debug option */
int setmtimeFlag; /* --setmtime. Set mtimes on files */
int nChng;/* Number of file renames */
@@ -136,10 +144,11 @@
}
}else{
width = -1;
}
latestFlag = find_option(latest,0, 0)!=0;
+ statusFlag = find_option(status,s,0)!=0;
dryRunFlag = find_option(dry-run,n,0)!=0;
if( !dryRunFlag ){
dryRunFlag = find_option(nochange,0,0)!=0; /* deprecated */
}
verboseFlag = find_option(verbose,v,0)!=0;
@@ -582,10 +591,11 @@
}
if( !internalUpdate ) undo_finish();
if( setmtimeFlag ) vfile_check_signature(tid, CKSIG_SETMTIME);
db_end_transaction(0);
}
+ if ( statusFlag ) fossil_exit(nUpdate==0);
}
/*
** Make sure empty directories are created
*/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On Sun, Oct 5, 2014 at 5:05 PM, David Mason dma...@ryerson.ca wrote: In the interests of getting into the code a bit, I looked at implementing this. Making it truly a quiet option was going to require fairly major surgery, but after a bit of thought, I realized that all I really needed was the exit status. I thought of making update always exit with this status (a 1-line change), but I was worried about legacy issues so I added that with a switch (patch attached - 1 line of code beyond declaring and parsing the switch). So instead of ``fossil update -q I would write ``fossil update -s -n /dev/null. I think this is better as it's more incremental and also more orthogonal. Gotta love users who provide patches :). + if ( statusFlag ) fossil_exit(nUpdate==0); } As you mention, there might be legacy issues pending there, but if there are, none of them are immediately obvious to me. The praise command says Andy B. has touched that code more often than anyone but Richard, so i'd be interested in hearing his opinion of it. It still seems horribly inefficient, though, considering all the db-level work it does there, knowing it's going to roll back the transaction. Another option comes to mind which would, i think, provide a one-call solution and might avoid major surgery: the ability to squelch output at the app level, such that fossil_print() and friends become no-ops when called when the squelch flag is set. For example (haven't tried this, just looked over the code): in main.c, (struct Global), add an integer member called disableOutput (it will be memset to 0 at startup, so use disableOutput instead of enableOutput). In fossil_print() (and similar output routines), check for that flag, doing nothing if it has a truthy value. In (fossil update), set that flag if --quiet is used. The question then becomes, do we squelch error messages, too? (And, if no, can we separate that output without more notable surgery. Initial brief analysis suggests that it wouldn't be too much work.) Care to take a crack at such a patch? The major funcs which would need a check for the flag are fossil_print() and (if error messages should also be hidden) fossil_fatal(). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On 5 October 2014 12:41, Stephan Beal sgb...@googlemail.com wrote: On Sun, Oct 5, 2014 at 5:05 PM, David Mason dma...@ryerson.ca wrote: Gotta love users who provide patches :). :-) + if ( statusFlag ) fossil_exit(nUpdate==0); } As you mention, there might be legacy issues pending there, but if there are, none of them are immediately obvious to me. The only thing that occurred to me was that (without the switch) a nothing-to-do run would have the same exit status as some fatal situation and someone somewhere might be dependent on fossil non-zero exit status implying some significant error. But as you say, it seems unlikely. It still seems horribly inefficient, though, considering all the db-level work it does there, knowing it's going to roll back the transaction. Except that only happens in the case where it's going to do some real work when I call it without the -n, versus Andy's suggested shell version that does a lot of work every 5 minutes. So I think this is the right trade-off. Also all that work is in-memory, is it not? And, with this running every 5 minutes, any change in the repo is likely to be from a single commit, so not that much changing. Another option comes to mind which would, i think, provide a one-call solution and might avoid major surgery: the ability to squelch output at the app level, such that fossil_print() and friends become no-ops when called when the squelch flag is set. Unless I'm missing something, this is to make a true -q option, right? I thought of this, but wasn't certain that all output was via fossil_print and fossil_fatal. Also for my case, redirecting output to /dev/null is perfectly reasonable. Care to take a crack at such a patch? The major funcs which would need a check for the flag are fossil_print() and (if error messages should also be hidden) fossil_fatal(). Sure, I could do that... but not likely until tomorrow. Continuing to think about it, my issue is that I don't want to send empty emails, an a look at mail(1) suggests that: fossil update -m | mail -E -s some subject m...@he.re would do exactly what I want if the -m switch suppressed all output unless it was actually doing something, since the -E switch on email suppresses the mail if the body is empty. This has the advantage that update is only called once, so there's no wasted DB work that needs to get undone, doesn't change the output status, or require any additional shell scripting or for the server to be running. So how about that? Andy? Thanks for the discussion... I think I've finally come to the cleanest solution. Sometimes we (I) need to forget about our possible solutions and remember what the real requirement is. ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On Sun, Oct 5, 2014 at 7:52 PM, David Mason dma...@ryerson.ca wrote: On 5 October 2014 12:41, Stephan Beal sgb...@googlemail.com wrote: Another option comes to mind which would, i think, provide a one-call solution and might avoid major surgery: the ability to squelch output at the app level, such that fossil_print() and friends become no-ops when called when the squelch flag is set. Unless I'm missing something, this is to make a true -q option, right? I thought of this, but wasn't certain that all output was via fossil_print and fossil_fatal. Also for my case, redirecting output to /dev/null is perfectly reasonable. Correct, this would be a true -q option, usable also by other routines for which quiet mode would be useful. fossil_print/fatal() would be the main ones, and if any other output filtered into your mailbox along the way, we could track those down as needed. Continuing to think about it, my issue is that I don't want to send empty emails, an a look at mail(1) suggests that: fossil update -m | mail -E -s some subject m...@he.re Ah, right, which isn't exactly the same as -q. Hmm. So how about that? Andy? Thanks for the discussion... I think I've finally come to the cleanest solution. Sometimes we (I) need to forget about our possible solutions and remember what the real requirement is. Which we often don't know until we deploy the first draft ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said David Mason on Sun, 05 Oct 2014 11:05:27 -0400: Absolutely. It should work fine and it's better than my original shell-only version. I don't really want to do it that way for a couple of reasons: 1) I don't want to *have* to be running a fossil server (I do updates via ssh); and 2) it seems like a lot of overhead (execution as well as old version files) and redundancy. For 1, you don't have to run a fossil server, you can fetch RSS updates via SSH too: ssh user@remote fossil rss -R /path/to/project.fossil As for 2, yes, I suppose you will end up with potentially 2 extra files for each repo (1 if you rm the $NEW when there are no changes). That doesn't seem like much to me, but I understand others may think differently. I'll agree that it is not as optimal as having Fossil tell you when there are changes (well, actually fossil rss publishes changes so it is possible to detect differences in changes as my script shows, so that's not entirely accurate). So instead of ``fossil update -q I would write ``fossil update -s -n /dev/null. I think this is better as it's more incremental and also more orthogonal. I think that if you use --dry-run, fossil update won't even sync; it is intended to show what would be updated to an existing name in the repository (e.g. fossil update -n branch5). This means it won't walk to the remote server and won't know about any changes. I could be wrong, but given that there currently is not a --dry-run for on-network sync operations, I believe that the challenge here will be to fake the sync protocol to the point where we know that there are changes, but don't send or receive any of the changes into the repository. Otherwise, you run into a different set of overhead problems (e.g. you pull down potentially large amounts of data, then rollback the commit for the sole purpose of reporting that there is data to be synced). Then we need to know what should be reported on. Do we report only if the list of artifacts that we have received includes direct descendents of our current checkout (which probably means parsing the manifests of those artifacts, which also implies that we have already downloaded those manifests)? Or take the simple approach and just report if there are new artifacts? Andy -- TAI64 timestamp: 400054322391 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said Stephan Beal on Sun, 05 Oct 2014 18:41:33 +0200: It still seems horribly inefficient, though, considering all the db-level work it does there, knowing it's going to roll back the transaction. Actually, at the moment, there isn't much inefficiency because it's all local. fossil update --dry-run is local only operation. It doesn't involve any network sync operations. I agree, however, that if fossil update --dry-run did network sync operations and combined with a new -s option would introduce a different set of inefficiencies---mainly that it would necessarily mean downloading potentially large file artifacts, parsing the manifests, and all the requisite DB updates, simply to detect that there are changes and report. Unless the report is naive and simply reports if there are any unseen artifacts (halting the sync operation after it has received the unclustered artifacts list and then checking the blob table for them). On the other hand, the case of fossil update -s seems clear enough, just run the update and exit non-zero if no updates were made. The question then becomes, do we squelch error messages, too? (And, if no, can we separate that output without more notable surgery. Initial brief analysis suggests that it wouldn't be too much work.) If one wants to squelch error messages shouldn't one just redirect stderr to /dev/null? :-) Andy -- TAI64 timestamp: 40005432262b ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said David Mason on Sun, 05 Oct 2014 13:52:45 -0400: Continuing to think about it, my issue is that I don't want to send empty emails, an a look at mail(1) suggests that: fossil update -m | mail -E -s some subject m...@he.re If you're using the scripted approach, just make the script conditionally send an email. E.g., if there are updates, update and send an email, otherwise don't do anything. Andy -- TAI64 timestamp: 400054322781 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said Andy Bradford on 05 Oct 2014 23:18:01 -0600: On the other hand, the case of fossil update -s seems clear enough, just run the update and exit non-zero if no updates were made. By the way, I'm not not necessarily suggesting that this be done. At the moment, fossil update does exit non-zero if there are sync errors (e.g. password failure, database locked, other remote server errors, etc...). I simply meant that -s as a use case makes more sense than a --dry-run that does faux sync operations. Andy -- TAI64 timestamp: 400054322a12 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Ah, yes; I forgot about autosync (I'm new to actually using fossil), but I don't think it's a flaw (see below). On 3 October 2014 01:21, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 2, 2014 at 3:35 PM, David Mason dma...@ryerson.ca wrote: fossil update -q fossil update 21 | mail -s 'Fossil update' m...@he.re i've been mulling over this, and there's one fundamental flaw here: if auto-sync is on (which it is by default), then fossil does not know if there's work to be done until after it has done the network sync. In the above operation, it would sync twice, _potentially_ with different results for each (classical race condition). Having the hypothetical -q option disable/bypass autosync doesn't seem like a solution because then its result could very well differ from that of the second update (which would sync, if enabled). When autosync is off, that wouldn't be a problem, but it is on by default and is highly recommended to avoid unintended forks (the reason it's turned on by default, IIRC, was unintended forks in fossil itself early on in Fossil's history). Suggestions for an alternative approach, or concrete semantics, are welcomed. If autosync is on and remote-url is on, then update -q should do the sync, and then check if there is work to do. Of course, if there are changes, but not on the branch the update refers to, then it returns false (this allows for e.g. an in-production branch). 4 points: 1) in my use case, this is the master repository, so has remote-url off so this isn't an issue. 2) this update will run every ?5? minutes,so if the update -q misses a change that the second update would get, it's no biggy... 5 minutes later will do fine (my alternative solution of checking timestamps wouldn't do any better) 3) if the second update finds more to do because of the second auto-sync, so much the better... and if not, the second autosync is a bit of extra network traffic, but again, no biggy 4) autosync on update actually obviates the need for the -q switch on sync (and as I think it through, sync doesn't need it anyway as either it found nothing to do in which case the update would have found nothing to do, or it changed things in which case the update would see the change (or not if the changes were to another branch)) Hope that is clear. Thanks ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said David Mason on Thu, 02 Oct 2014 09:35:50 -0400: I want a script to run every 5 minutes and if there is any update, email me the update log. But I don't want email every 5 minutes that just says everything is up to date. I can figure out using file timestamps etc. if an update is necessary, but that's pretty ugly. Why not use Fossil's RSS feed feature to detect changes? Andy -- TAI64 timestamp: 4000542ece22 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On 3 October 2014 12:25, Andy Bradford amb-sendok-1414945537.ohnacbkbmfbammcpp...@bradfords.org wrote: Thus said David Mason on Thu, 02 Oct 2014 09:35:50 -0400: I want a script to run every 5 minutes and if there is any update, email me the update log. But I don't want email every 5 minutes that just says everything is up to date. I can figure out using file timestamps etc. if an update is necessary, but that's pretty ugly. Why not use Fossil's RSS feed feature to detect changes? I looked at it. 3 reasons present themselves to me: 1) I may not be running a server (I'm not right now... this may change). 2) I'd have to parse the XML, at least minimally. It looks like I can parse the fossil stat to find the current checkout and then look for that in the output of: http://localhost:8080/XXX/timeline.rss?y=cin=1tag=trunk but that seems kind of kludgey 3) It seems like a lot more overhead, compared to a local run of fossil That said, if the powers that be (PTB) don't like the idea, rss does provide a fallback, thanks. ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said David Mason on Fri, 03 Oct 2014 12:49:17 -0400:
3) It seems like a lot more overhead, compared to a local run of fossil
I'm not sure why you need to parse anything. Here is a low-overhead
script that detects updates to a remote repository:
#!/bin/sh
OLD=$HOME/old.rss
NEW=$HOME/new.rss
touch $OLD
curl -s 'http://www.fossil-scm.org/index.html/timeline.rss?y=citag=trunk' |
sed -e '/pubDate/d' /tmp/new.rss
diff $OLD $NEW /dev/null || {
cp -f $NEW $OLD
echo new check-ins on trunk
exit 0
}
echo no new check-ins on trunk
exit 1
But, this raises the question... if you're just trying to determine when
to update, why not just run ``fossil update'' on a schedule? You
mentioned that fossil knows when it has ``work to do'' but I'm not sure
I understand exactly what you mean by it. Fossil certainly knows when it
should transfer content from the remote side to the local side and vice
versa. It also knows when it should merge files into your working
checkout (because fossil update causes this to happen).
Here was the original example:
fossil update -q fossil update 21 | mail -s 'Fossil update' m...@he.re
Are you simply looking for a way to be notified via email when there are
changes that have been updated into your working checkout? If so, I
think the above script could be substituted for ``fossil update -q'':
shouldiupdate.sh fossil update 21 | mail -s 'Fossil update' m...@he.re
Andy
--
TAI64 timestamp: 4000542ee560
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On Thu, Oct 2, 2014 at 9:35 AM, David Mason dma...@ryerson.ca wrote: While I'm on fossil sync, is there a way to reset the sync source value? For whatever reason (actually because it was easier to update privileges on my laptop than my headless server) I copied a client fossil to the server and now if I try to fossil sync on the server it tries to log into itself. I think, if you provide a URL when sync'ing, Fossil remembers that. That said, the script that I use to backup my Fossil repos always supplies the URL to the Fossil server running on the back up server. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On 2 October 2014 11:02, Ron W ronw.m...@gmail.com wrote: On Thu, Oct 2, 2014 at 9:35 AM, David Mason dma...@ryerson.ca wrote: While I'm on fossil sync, is there a way to reset the sync source value? I think, if you provide a URL when sync'ing, Fossil remembers that. That said, the script that I use to backup my Fossil repos always supplies the URL to the Fossil server running on the back up server. Yes, I know that, but I want it to *forget* about that remembered URL so that if I do a sync from a script it won't try to sync with a no-longer-relevant source. ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
2014-10-02 15:35 GMT+02:00 David Mason dma...@ryerson.ca: While I'm on fossil sync, is there a way to reset the sync source value? Is fossil remote-url what you want? Goyo ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On Thu, Oct 2, 2014 at 7:02 PM, Goyo goyod...@gmail.com wrote: 2014-10-02 15:35 GMT+02:00 David Mason dma...@ryerson.ca: While I'm on fossil sync, is there a way to reset the sync source value? Is fossil remote-url what you want? That's the simplest solution, or... i believe what Ron intended was that you pull once manually with the now-relevant URL, and then you don't need it in your scripts anymore. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/2/2014 12:40 PM, David Mason wrote: Right, what I wanted to do was get rid of the remote-url. It turns out that if you say: fossil remote-utl '' it complains that it's invalid, but now it's off, so it no longer attempts to sync. Type: fossil remote-url off - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJULaHHAAoJELtYwrrr47Y4vOYH/j/uP+ZUaHZeO/RItqvW3jxe rOoN5MfUs+aIcpeFZapUvcZnpIksnjZsC8o2f/QFMK9DxT/RBx1uCXWOWXyYsuQm 9kuvohBpAM5haGLEwu9WEdYZzS6ca1M5UfubOETEbTq71Dn+t4LRnM60a44Wdb+0 +vGd6rCWmyyfZ0BZrSGRSM0agWYRk/TFijbJeJ8XTgl575MNzI8K+Fv74bKzA6Dk izA1cLeA/n6G+PkDlOksZAB/sEOr2dG6u2qXujSCgTJ5j4gGDDNigC4MpdaENU0k w3JydEr/eys/P+9YhXAUy/r4erkV+4O1i9ogmOf1y3mcDWptynOwoYIctNJSfIY= =qu8Q -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On 2 October 2014 15:04, Andy Goth andrew.m.g...@gmail.com wrote: Type: fossil remote-url off Ah, much cleaner! Thanks, missed that. ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Date: Thu, 2 Oct 2014 13:40:06 -0400 From: David Mason dma...@ryerson.ca To: Fossil SCM user's discussion fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Quiet mode for update and sync Message-ID: CALFgxqD_Gg_2FtkSs=82r0vnvmkrctz-4lxnejefqp7dckn...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Right, what I wanted to do was get rid of the remote-url. It turns out that if you say: fossil remote-utl '' it complains that it's invalid, but now it's off, so it no longer attempts to sync. Thanks ../Dave I thought you could do: fossil remote-url off At least, according to the help: f help remote f.exe remote-url ?URL|off? Tomek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
On Thu, Oct 2, 2014 at 3:35 PM, David Mason dma...@ryerson.ca wrote: fossil update -q fossil update 21 | mail -s 'Fossil update' m...@he.re i've been mulling over this, and there's one fundamental flaw here: if auto-sync is on (which it is by default), then fossil does not know if there's work to be done until after it has done the network sync. In the above operation, it would sync twice, _potentially_ with different results for each (classical race condition). Having the hypothetical -q option disable/bypass autosync doesn't seem like a solution because then its result could very well differ from that of the second update (which would sync, if enabled). When autosync is off, that wouldn't be a problem, but it is on by default and is highly recommended to avoid unintended forks (the reason it's turned on by default, IIRC, was unintended forks in fossil itself early on in Fossil's history). Suggestions for an alternative approach, or concrete semantics, are welcomed. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
