Re: [fossil-users] How to limit fossil diff output to just names of the changed files?
On Tue, Jan 31, 2012 at 21:30, Matt Welland estifo...@gmail.com wrote: fossil could do with a little more power on the command line. Passing remaining parameters to diff would be useful. Here is a crude work around for you: $ fossil set diff-command 'diff $DIFFPARAMS' $ DIFFPARAMS='-q' fossil diff -r 7ad3e Matt, under close inspection the output of the external diff -q is pretty much useless. $ fossil clone http://www.fossil-scm.org/ fossil.fos $ fossil set diff-command 'diff $DIFFPARAMS' -R fossil.fos $ DIFFPARAMS='-q' fossil diff --from version-1.20 --to version-1.21 -R fossil.fos produces Files /var/tmp/TOVfAuDTszthuDY and /var/tmp/FdEbKPAZ0uv66ad differ Files /var/tmp/FDjccX0cYFeqRl4 and /var/tmp/lqsmmIbXyNVtinB differ Files /var/tmp/6mOoNpHpm360YzI and /var/tmp/P5R9MqHCWsOmqcr differ ... Exernal diff is being called on temporary files in /var/tmp with non-descriptive names. I am using fossil-1.21 on Linux. Is it a bug or I am doing something wrong? --Leo-- ___ 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] documentation clarification
On Wed, Feb 1, 2012 at 4:42 AM, Leo Razoumov slonik...@gmail.com wrote: I am reading Fossil File Formats at http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki where it says (section on Control Artifacts): When two or more tags with the same name are applied to the same artifact, the tag with the latest (most recent) date is used. Most recent date according to what clock? Fossil is distributed and clocks on different machines can be out of sync with each other so are artifact's timestamps. Can it cause problems? Am I missing something? Internally fossil uses a mix of Unix timestamps and (mostly, AFAIK) Julian dates. Unix timestamps are GMT/UTC and Julian is, as far as i'm aware, also timezone-independent. (Maybe someone better-versed in time handling can correct my Julian understanding.) http://en.wikipedia.org/wiki/Julian_day Commits/changes are performed on the client (then synched to the server), which implies that the timestamps are local and that a clock drift on a local machine will result in funky data on the server. (But again, perhaps someone here can correct that assumption.) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] documentation clarification
On Tue, Jan 31, 2012 at 10:42 PM, Leo Razoumov slonik...@gmail.com wrote: Hi List, I am reading Fossil File Formats at http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki where it says (section on Control Artifacts): When two or more tags with the same name are applied to the same artifact, the tag with the latest (most recent) date is used. Most recent date according to what clock? Fossil is distributed and clocks on different machines can be out of sync with each other so are artifact's timestamps. Can it cause problems? Am I missing something? The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ 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] repository for tarball and zip
On Wed, Feb 1, 2012 at 5:37 AM, Kevin Quick qu...@sparq.org wrote: And so it does. Sorry, I should have tried it first. I was going solely on the $ fossil help tarball output, which should probably be updated to mention this. Then it was a doc bug in any case. Now fixed - thanks for the report. [stephan@host:~/cvs/fossil/fossil/src]$ f com -m 'Doc change only: documented -R/--repository for zip/tar commands.' zip.c tar.c ... New_Version: a84aadad5a76cfdf6d9586e62aba322a8e92255c -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] documentation clarification
On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. Hopefully, this issue is of no practical importance, for one can always correct errors later on by pushing yet another tag. --Leo-- ___ 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] documentation clarification
On Wed, Feb 1, 2012 at 9:03 AM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. Just to be clear, Fossil does not use timestamps in constructing its DAG either. If the timestamps are off, then the graph looks a little weird (ex: http://www.sqlite.org/src/timeline?c=2010-09-29nd) but everything still works. But for some things, like tags, that do not have a parent/child relationship, timestamps are necessary for ordering events. If your system clock is off, you would do well to activate an NTP daemon on your machine. Fossil itself has no difficulty working with misconfigured system clocks, but the resulting project history becomes more difficult for humans to follow. Hopefully, this issue is of no practical importance, for one can always correct errors later on by pushing yet another tag. --Leo-- -- D. Richard Hipp d...@sqlite.org ___ 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] documentation clarification
On Wed, 2012-02-01 at 09:03 -0500, Leo Razoumov wrote: On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. Hopefully, this issue is of no practical importance, for one can always correct errors later on by pushing yet another tag. --Leo-- The wonders of the internet include the Network Time Protocol (http://www.ntp.org/) and I think all major operating systems have a mechanism for enabling it, if that is not the default. It is then possible to have synchronised time keeping to a meaningful level of precision. I can't speak for MS-Windows or MacOS but Ubuntu Linux uses NTP by default. ___ 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] documentation clarification
On Wed, 01 Feb 2012 10:18:18 -0400 Chris Peachment ch...@ononbb.com wrote: [...] The wonders of the internet include the Network Time Protocol (http://www.ntp.org/) and I think all major operating systems have a mechanism for enabling it, if that is not the default. It is then possible to have synchronised time keeping to a meaningful level of precision. I can't speak for MS-Windows or MacOS but Ubuntu Linux uses NTP by default. Windows (at least, since Windows XP) has native NTP client which one just have to set up more sensibly. For instance, [1] appears to be a quite sensible guide. 1. http://www.cumps.be/nl/blog/read/howto-set-up-ntp-on-windows-vista ___ 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] documentation clarification
Leo Razoumov wrote: Hopefully, this issue is of no practical importance, for one can always correct errors later on by pushing yet another tag. As with cryptography, keeping your clock up to date is essentiel... -- urban jc...@i2pmail.org http://chiselapp.com/user/jcage/repository/rdk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] PATCH included: Re: How to limit fossil diff output to just names of the changed files?
On Wed, Feb 1, 2012 at 10:11, Matt Welland estifo...@gmail.com wrote:
$ fossil set diff-command 'diff $DIFFPARAMS'
$ DIFFPARAMS='-q' fossil diff -r 7ad3e
It looks to me like fossil has a bug where output ordering is messed up when
you pipe to another program. The Index: ... lines are all pushed to the
end out output if output is to a pipe:
Matt,
yes, I see the same problem with Index: lines on Linux when piping the output.
It happens because fossil does not flush stdout when outputs those
lines and then it gets messy when external diff subprocesses write to
the same stream. The following one-line patch solved this problem for
me. Please, give it a try. I hope it does not break anything:-)
--Leo--
Index: src/diffcmd.c
==
--- src/diffcmd.c
+++ src/diffcmd.c
@@ -32,10 +32,11 @@
cgi_vprintf(zFormat, ap);
}else{
vprintf(zFormat, ap);
}
va_end(ap);
+ fflush(stdout);
}
/*
** Print the Index: message that patches wants to see at the top of a diff.
*/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
