[fossil-users] Fingerprinting a fossil repository

Hi all - I've got a lot of fossil repositories, and for backup purposes I encrypt and upload them to "cloud storage". The backup process runs every night, but I don't want to upload repos which haven't changed. My initial thought was that I could just do an sha1 hash of the repo. But it turns o

Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

On Wed, Aug 21, 2013 at 08:05:58PM -0600, Chad Perrin wrote: > On Wed, Aug 21, 2013 at 06:03:50PM -0700, B Harder wrote: > > Agreed. Hyphens in libnames don't look pleasing to my eye (fwiw), > > libfossilscm (cc ... -lfossilscm ...) might be next best to > > disambiguate from potential collision w/

Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

On Wed, Aug 21, 2013 at 06:03:50PM -0700, B Harder wrote: > Agreed. Hyphens in libnames don't look pleasing to my eye (fwiw), > libfossilscm (cc ... -lfossilscm ...) might be next best to > disambiguate from potential collision w/ another libfossil, though it > too is pretty ugly looking. > > Brie

Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

Agreed. Hyphens in libnames don't look pleasing to my eye (fwiw), libfossilscm (cc ... -lfossilscm ...) might be next best to disambiguate from potential collision w/ another libfossil, though it too is pretty ugly looking. Brief search yields https://github.com/paulfitz/libfossil as second hit (a

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 2:29 PM, j. van den hoff wrote: > On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal > wrote: > > On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen > >wrote: >> >> The fossil rebuild logic uses a two pass algorithm. I am not quite sure >>> why this is necessary, it could have

Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

On Wed, Aug 21, 2013 at 07:45:53PM +0200, Stephan Beal wrote: > On Wed, Aug 21, 2013 at 7:43 PM, Mark Janssen wrote: > > > > +1 for libfossil. I hate it when libraries have smart names requiring me > > to google for the package name to install. > > BTW (should have noted this earlier): there is a

Re: [fossil-users] strange `fossil diff ' behaviour

On 21 Aug 2013 23:22, "j. van den hoff" wrote: > > On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen wrote: > >> On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff >> wrote: >> >>> On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen >>> wrote: >>> >>> To make this less of an academic discussion and t

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 11:22 PM, j. van den hoff wrote: > understood. what I do not get is (apart from that's it probably not part > of the current machinery) why it > would be complicated (for the people in the know) to just log the checkins > and count them while they arrive in the db i've b

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal wrote: On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen wrote: The fossil rebuild logic uses a two pass algorithm. I am not quite sure why this is necessary, it could have something to do with delta manifests. At http://mpcjanssen.nl/fossi

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen wrote: On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff wrote: On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen wrote: To make this less of an academic discussion and to just be able to play very good point (despite being myself in aca

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen wrote: > The fossil rebuild logic uses a two pass algorithm. I am not quite sure > why this is necessary, it could have something to do with delta manifests. > At http://mpcjanssen.nl/fossil/fossil/timeline?r=revlist I have changed > this to a single

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff wrote: > On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen > wrote: > > To make this less of an academic discussion and to just be able to play >> > > very good point (despite being myself in academia ...) and thanks a lot > for sharing this. > > >

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen wrote: To make this less of an academic discussion and to just be able to play very good point (despite being myself in academia ...) and thanks a lot for sharing this. around with it, http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:

Re: [fossil-users] Command-line wildcards

@Richard: My guess is that the one of the prebuild binaries was compiled with MinGW > and the other with MSVC. Just to provide some information so you can verify your guess: I've been using fossil since years now, (on XP, Vista, and now Win7,) and I updated regularly (though I can't be sure I go

Re: [fossil-users] Command-line wildcards

On Wed, Aug 21, 2013 at 7:43 PM, wrote: > @Stephan Beal: Thanks man. And I'll admit I might have been a tick too > sensible about it. :-) > ...Anyway, I did not want to go in too deep about the whole matter. I > thought you guys would want feedback on issues because it is a chance to > improve th

Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

On Wed, Aug 21, 2013 at 7:43 PM, Mark Janssen wrote: > +1 for libfossil. I hate it when libraries have smart names requiring me > to google for the package name to install. > BTW (should have noted this earlier): there is a filesystem called "fossil", and while i have not found a libfossil namin

Re: [fossil-users] Command-line wildcards

@Stephan Beal: Thanks man. And I'll admit I might have been a tick too sensible about it. :-) I'm very well aware that Windows is a bloated piece of ... code full of deficiencies. But if something used to work well up to a certain version (I'm using fossil since years, could have been 0.something

Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

On Wed, Aug 21, 2013 at 7:38 PM, Stephan Beal wrote: > On Wed, Aug 21, 2013 at 7:30 PM, Themba Fletcher < > themba.fletc...@gmail.com> wrote: > >> What about "libfree" as a portmanteau of lib, fossil, and three? I guess >> that crosses the line into humor a bit. >> > > And sounds very GNU :/. > >

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 7:36 PM, Stephan Beal wrote: > On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen wrote: > >> Currently the revision numbers are reflecting the fossil rebuild >> algorithm so they count down from leaves which is a bit odd, but that can >> probably be improved. >> > > Coincident

Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

On Wed, Aug 21, 2013 at 7:30 PM, Themba Fletcher wrote: > What about "libfree" as a portmanteau of lib, fossil, and three? I guess > that crosses the line into humor a bit. > And sounds very GNU :/. > More seriously though, fossil(3) is my favorite, but it does make it sound > like it's an offi

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen wrote: > Currently the revision numbers are reflecting the fossil rebuild algorithm > so they count down from leaves which is a bit odd, but that can probably be > improved. > Coincidentally, this block _might_ affect you in a negative way: http://m

Re: [fossil-users] strange `fossil diff ' behaviour

To make this less of an academic discussion and to just be able to play around with it, http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlist&to=r:5746&sbs=1 has an implementation of having repository local rev numbers for commits only. After updating fossil you'll need to do a fossil rebuild

Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

Ooh, I love bikeshedding. What about "libfree" as a portmanteau of lib, fossil, and three? I guess that crosses the line into humor a bit. More seriously though, fossil(3) is my favorite, but it does make it sound like it's an official part of the fossil project and actually implies, at least to

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 8:37 AM, Matt Welland wrote: > Regarding stable numbered tags. How about a script or added feature that > scans the timeline and tags every node in a systematic way similar to what > people might expect from Subversion or similar tools? > > v1.1 -> v1.2 -> v1.3 > \.-

[fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name

Hi, all, The current list of "upvoted" names (no, Brad, urvogel's not one of them ;) for the on-going/up-coming library API includes (in my personal order of preference, but i'm not emotionally attached to these): - libfossil-scm and fossil(3) - libfossil - liblissof (fossil, backwards, because t

Re: [fossil-users] strange `fossil diff ' behaviour

I'll reply to this mail again, since it is essentially the only one exactly addressing my point: -- I agree that any non-local use of revnums is doomed to failure (with checkins tickets or whatever). -- we don't need some new `svn' like naming scheme of revisions instead of the hashes (1.

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 5:43 PM, Stephan Beal wrote: > Side-note... > > the library interface will allow clients to add this sort of supplemental > metadata/functionality, and will eventually provide enough > Side-note #2/shameless plug: the library effort is coming along nicely but more collabo

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 5:37 PM, j. van den hoff wrote: > thanks for this clarification. so, while you don't share my view that the > sequential revnums (yes: exactly the same thing as in mercurial) are a good > thing, I still do (from some years of usage of mercurial). I've tried to > argue for t

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, 21 Aug 2013 17:10:59 +0200, Stephan Beal wrote: On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson wrote: On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal wrote: > DVCSs cannot, by their very nature, portably support sequential numbers. > This topic has been beaten to death by brains m

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, 21 Aug 2013 17:09:52 +0200, Richard Hipp wrote: On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson wrote: On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal wrote: > DVCSs cannot, by their very nature, portably support sequential numbers. > This topic has been beaten to death by brains mu

Re: [fossil-users] strange `fossil diff ' behaviour

Regarding stable numbered tags. How about a script or added feature that scans the timeline and tags every node in a systematic way similar to what people might expect from Subversion or similar tools? v1.1 -> v1.2 -> v1.3 \.-> v1.1.1 If the script worked incrementally and was run centrally

Re: [fossil-users] strange `fossil diff ' behaviour

For most of the use cases discussed here I think we don't need repository local unique numbers a la mercurial. As far as I can see a more flexible VERSION [1] format (although the git way is probably overkill) seems to be enough. It would be useful for example to be able to say: fossil diff -r -2

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 5:26 PM, Mark Janssen wrote: > One reason which would make my life easier is when dealing with tickets, > it is much easier to discuss bug 12 (in blessed repo X) instead of ticket > uuid [some 8+ digit number]. When I work with tickets on github I know the > bug ids of tic

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 11:26 AM, Mark Janssen wrote: > > One reason which would make my life easier is when dealing with tickets, > it is much easier to discuss bug 12 (in blessed repo X) instead of ticket > uuid [some 8+ digit number]. When I work with tickets on github I know the > bug ids of t

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 5:09 PM, Richard Hipp wrote: > On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson wrote: > >> On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal >> wrote: >> > DVCSs cannot, by their very nature, portably support sequential numbers. >> > This topic has been beaten to death by bra

Re: [fossil-users] getting fossil timeline to show time offsets

In TCC (a CMD replacement for windows), I use the following where %_unixtime is a variable representing the current time. echo insert into config (name,value,mtime) values ("timeline-utc",0,%_unixtime); | fossil sql From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@l

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 5:10 PM, Stephan Beal wrote: > such problems if they cannot be reproduced easily. i could see it being > halfway reliable for diffs, but not commits, because any change to the > filesystem or repo can change the list of files used by the commit command. > A silly but very

Re: [fossil-users] Control artifact types [Was: Minor new feature: comments when closing/re-opening]

On Wed, Aug 21, 2013 at 5:19 PM, Stephan Beal wrote: > Here's the algo fossil(3) uses to figure the artifact type out at > parse-time. So far i haven't been able to fool it using exported manifests: > > > http://fossil.wanderinghorse.net/repos/f2/index.cgi/artifact/53a6ffa8e3f2c499cc2531d3201b98f

Re: [fossil-users] Control artifact types [Was: Minor new feature: comments when closing/re-opening]

On Wed, Aug 21, 2013 at 5:13 PM, Jan Nijtmans wrote: > I'm looking at the algorithm in fossil now which determines the > type. Most types are easy to distinguish because they have unique > cards which only occur in that type. The only difficult types are > Control artifacts and Manifests: The card

Re: [fossil-users] strange `fossil diff ' behaviour

last mail in these matters since it is in danger of deteriorating into just another flame. On Wed, 21 Aug 2013 16:36:58 +0200, Stephan Beal wrote: On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff wrote: with due respect, that's too dogmatic for my taste. and it's also a question what yo

[fossil-users] Control artifact types [Was: Minor new feature: comments when closing/re-opening]

2013/8/19 Stephan Beal : > As long as the artifact types are syntactically unambiguous, meaning it's > always possible to determine their type based on their card letters (letters > only, ignoring the card parameters), i'm happy :). Any ambiguity would > potentially open up a big can of worms for b

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson wrote: > On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal > wrote: > > DVCSs cannot, by their very nature, portably support sequential numbers. > > This topic has been beaten to death by brains much larger than mine. > > Joerg's original proposal (in a

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson wrote: > On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal > wrote: > > DVCSs cannot, by their very nature, portably support sequential numbers. > > This topic has been beaten to death by brains much larger than mine. > > Joerg's original proposal (in a

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal wrote: > DVCSs cannot, by their very nature, portably support sequential numbers. > This topic has been beaten to death by brains much larger than mine. Joerg's original proposal (in a previous thread) was to support _local_ sequential revision number

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff wrote: > with due respect, that's too dogmatic for my taste. and it's also a > question what you decide to include > Domagtic, it is. It is a fact of software development, in particular long-lived software, that once an internal implementation deta

Re: [fossil-users] strange `fossil diff ' behaviour

unintentionally replied only to stephan, but this should stay on th list, I'd say, so: On Wed, 21 Aug 2013 16:08:16 +0200, Stephan Beal wrote: On Wed, Aug 21, 2013 at 3:25 PM, j. van den hoff wrote: "philosophical" issues aside: does that mean that with the current implementation (and prob

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 1:50 PM, Richard Hipp wrote: > Furthermore, this feature is for debugging use only and should not get in > the way of end users. Perhaps it should be changed such that the record ID > is only used if the input begins with "rid:"? > Just checked in: stephan@tiny:~/cvs/fo

Re: [fossil-users] Command-line wildcards

On Wed, Aug 21, 2013 at 3:18 PM, wrote: > Uh? My question was about the mailman mailing list?!? How is that related > to Windows? > Because your top-post came immediately after such a question i took it out of context. In any other respect, I take your response as rather... snobbish. Not sure >

Re: [fossil-users] Command-line wildcards

On Wed, Aug 21, 2013 at 9:23 AM, wrote: > Uhm, perhaps a naive "outsider" question, but how came the issue wasn't > there before 1.25, if it's the differences in how the different shells > process CLI arguments? Did the shells not remain the same in between? > > My guess is that the one of the pr

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, 21 Aug 2013 13:25:50 +0200, Stephan Beal wrote: On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff wrote: On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal wrote:0. intentionally undocumented or did nobody manage to add it to the manpages? Intentional - see the comment line at t

Re: [fossil-users] Command-line wildcards

Uhm, perhaps a naive "outsider" question, but how came the issue wasn't there before 1.25, if it's the differences in how the different shells process CLI arguments? Did the shells not remain the same in between? On Wed, Aug 21, 2013 at 3:02 PM, Mark Janssen - mpc.jans...@gmail.com < fossilscm.zo

Re: [fossil-users] commits from host A sometimes not seen on B

One thing to add here, is that when this happened for us, I had two different clones, one in a VM, and one on my workstation, and both of these couldn't see the 'faulty' commit until I re-cloned the repo (on both). So it seems to be a feature of the commit (or the copy that hits the server) rather

Re: [fossil-users] Command-line wildcards

@Stephen: But since I must accept the culture of the place I'm visiting, perhaps you > can help out a novice mailman list fellow: Is there any way to only receive > emails from threads I am participating in? > i haven't used Windows (outside of customer sites and an occasional game of > Empire at

Re: [fossil-users] Command-line wildcards

2013/8/21 Mark Janssen : > Sorry for spamming, but with the change it works within msys, but it fails > on the windows command line. Seems like a bit of a Catch 22 caused by the > different idea windows and unix have about how to pass arguments. See:

Re: [fossil-users] commits from host A sometimes not seen on B

On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin wrote: > > > > That sounds familiar. For the record, let me say I never (ever) make > > branches; all work here is done on trunk. > > In the repository where a fellow developer and I have seen this problem, > there have been no intentional branches mad

Re: [fossil-users] Command-line wildcards

Sorry for spamming, but with the change it works within msys, but it fails on the windows command line. Seems like a bit of a Catch 22 caused by the different idea windows and unix have about how to pass arguments. On Wed, Aug 21, 2013 at 2:52 PM, Mark Janssen wrote: > Yes, for example fossil

Re: [fossil-users] Command-line wildcards

Yes, for example fossil add * will still do the right thing. On Wed, Aug 21, 2013 at 2:51 PM, Stephan Beal wrote: > On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen wrote: > >> I did not test this with the 64bit version of MinGW. Using an unquoted * >> in this case still works as expected. >> > >

Re: [fossil-users] Command-line wildcards

On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen wrote: > I did not test this with the 64bit version of MinGW. Using an unquoted * > in this case still works as expected. > "as expected" means, i assume: resolves to a list of all files matching "*" in the current directory? (That's the expected Uni

Re: [fossil-users] commits from host A sometimes not seen on B

On Wed, Aug 21, 2013 at 08:37:43AM +0200, Michai Ramakers wrote: > On 21 August 2013 05:25, Donny Ward wrote: > > > > I get the same problem every once in awhile. Many times actually. I consider > > myself a heavy fossil user. My most active repository has 1087 checkins all > > made by me. > > > >

Re: [fossil-users] Command-line wildcards

Following change fixes it for met with MinGW 32 bit on windows 7. $ fossil diff src/main.c argc in wmain 3 --- src/main.c +++ src/main.c @@ -522,11 +522,13 @@ */ #if defined(_WIN32) && !defined(BROKEN_MINGW_CMDLINE) int _dowildcard = -1; /* This turns on command-line globbing in MinGW-w64 */ i

Re: [fossil-users] commits from host A sometimes not seen on B

On Sun, Aug 18, 2013 at 05:20:35PM +0200, Michai Ramakers wrote: > > 1) on host S: clone project from host S (http://S/my_repo) > 2) on host C: clone project from host S (http://S/my_repo) > 3) on host C: do some work, and commit changes > 4) on host S, 'fossil up' > 5) on host S: 'fossil timeline

Re: [fossil-users] Command-line wildcards

On Wed, Aug 21, 2013 at 8:31 AM, wrote: > @ > Stephan Beal: So fossil is refusing to eat it's own "dog food" - or rather one > of its more unique assets: The integrated wiki and ticket system? :-) > > We find that anonymously contributed tickets and wiki are generally of low quality, and not the

Re: [fossil-users] Command-line wildcards

It's a problem with the way MinGW parses and passes the command line. When main is called in fossil, the arguments are already expanded. As for the fix, I am not sure yet. On Wed, Aug 21, 2013 at 2:36 PM, Stephan Beal wrote: > > On Wed, Aug 21, 2013 at 2:31 PM, wrote: > >> @ >> Stephan Beal:

Re: [fossil-users] Command-line wildcards

On Wed, Aug 21, 2013 at 2:31 PM, wrote: > @ > Stephan Beal: So fossil is refusing to eat it's own "dog food" - or rather one > of its more unique assets: The integrated wiki and ticket system? :-) > This problem is Windows-specific. In every Unix shell "*.css", '*.css" will be equivalent (they

Re: [fossil-users] Command-line wildcards

@ Stephan Beal: So fossil is refusing to eat it's own "dog food" - or rather one of its more unique assets: The integrated wiki and ticket system? :-) But since I must accept the culture of the place I'm visiting, perhaps you can help out a novice mailman list fellow: Is there any way to only rece

Re: [fossil-users] commit signing

On Wed, Aug 21, 2013 at 1:58 PM, John Long wrote: > If I understood what you wrote, the checkin manifest is some kind of meta > data about the commit Correct. It tells us what blobs (stored separately) belong to the commit and hold some metadata for it (comment text, user name,...) > and the

Re: [fossil-users] Command-line wildcards

Thanks for the advice. However, I had already tried the single quote thing earlier, but I dismissed it, because AFAIK single quotes are not handled as string delimiters in the Windows shell, and: $ fossil set ignore-glob *.xxx > $ fossil set ignore-glob > ignore-glob (local) *.xxx But:

Re: [fossil-users] Command-line wildcards

Just re-confirmed: $ fossil set ignore-glob "*.css" > Usage: fossil set ?PROPERTY? ?VALUE? > $ fossil ver > This is fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC On Wed, Aug 21, 2013 at 2:10 PM, Zoran Isailovski wrote: > @Jan: Nope it's not fixed in 1.26. > > In fact I noticed it wi

Re: [fossil-users] Command-line wildcards

@Jan: Nope it's not fixed in 1.26. In fact I noticed it with 1.26, then regressed to 1.25 to check if the bug was there, then to 1.24. (I intentionally used the plus sign when referring to 1.25+) On Wed, Aug 21, 2013 at 1:56 PM, Jan Nijtmans - jan.nijtm...@gmail.com < fossilscm.zoc.1c6a0fe4b8.ja

Re: [fossil-users] Command-line wildcards

2013/8/21 Jan Nijtmans : > 2013/8/21 : >> In a directory that contains several .* files and subfolders, several *.css >> files and a single .php file, the following work fine with version 1.24, but >> only output a usage info with 1.25+ ("fossil: Usage: fossil set ?PROPERTY? >> ?VALUE?"): > > This

Re: [fossil-users] Command-line wildcards

On Wed, Aug 21, 2013 at 1:49 PM, wrote: > I actually wanted to simply post a bug report to the ticket system, but > it's telling me it will be deleted unless I go through the hoops of the > mailing list registration process. (Uh?!? Why then technically enable > anonymous ticket submissions in the

Re: [fossil-users] commit signing

On Tue, Aug 20, 2013 at 09:28:00PM +0200, Stephan Beal wrote: > On Tue, Aug 20, 2013 at 9:03 PM, John Long wrote: > > My understanding is you already compute checksums on commits. > > > At a lot of places. "Blob content" is referenced by its content SHA1, so > any change there invalidates it. A

Re: [fossil-users] Command-line wildcards

2013/8/21 : > In a directory that contains several .* files and subfolders, several *.css > files and a single .php file, the following work fine with version 1.24, but > only output a usage info with 1.25+ ("fossil: Usage: fossil set ?PROPERTY? > ?VALUE?"): This is already fixed in version 1.26.

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 1:48 PM, Richard Hipp wrote: > In fact, I thought that was the way it worked, though I haven't looked at > the code lately and I might have missed something. > That is how it works - it's a last-ditch effort before returning 0. Adding an rid: prefix to it is a good idea -

Re: [fossil-users] Command-line wildcards

Yes, I did. (That was my 1st thought, too.) Sorry, forgot to mention it. On Wed, Aug 21, 2013 at 1:51 PM, Richard Hipp - d...@sqlite.org < fossilscm.zoc.5877ad8d94.drh#sqlite@ob.0sg.net> wrote: > On Wed, Aug 21, 2013 at 7:49 AM, wrote: > >> I actually wanted to simply post a bug report to t

Re: [fossil-users] Command-line wildcards

On Wed, Aug 21, 2013 at 7:49 AM, wrote: > I actually wanted to simply post a bug report to the ticket system, but > it's telling me it will be deleted unless I go through the hoops of the > mailing list registration process. (Uh?!? Why then technically enable > anonymous ticket submissions in the

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 7:48 AM, Richard Hipp wrote: > On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal wrote: > >> >> On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff < >> veedeeh...@googlemail.com> wrote: >> >>> On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal >>> wrote:0. >>> intentionally undo

[fossil-users] Command-line wildcards

I actually wanted to simply post a bug report to the ticket system, but it's telling me it will be deleted unless I go through the hoops of the mailing list registration process. (Uh?!? Why then technically enable anonymous ticket submissions in the 1st place?) Oh well... My findings: In a direct

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal wrote: > > On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff < > veedeeh...@googlemail.com> wrote: > >> On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal >> wrote:0. >> intentionally undocumented or did nobody manage to add it to the >> manpages? >> >

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff wrote: > On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal > wrote:0. > intentionally undocumented or did nobody manage to add it to the manpages? > Intentional - see the comment line at the start of that block. > 1. > I don't hope this happens w

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal wrote: On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff wrote: hopefully not a stupid question: what's going on here? can someone confirm this? there is no checkin with a SHA1 hash starts with 5731 (or contain it) it seems. An undo

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 12:58 PM, Stephan Beal wrote: > > On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff < > veedeeh...@googlemail.com> wrote: > >> hopefully not a stupid question: what's going on here? can someone >> confirm this? there is no checkin with a SHA1 hash starts with 5731 (or >> co

Re: [fossil-users] strange `fossil diff ' behaviour

On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff wrote: > hopefully not a stupid question: what's going on here? can someone confirm > this? there is no checkin with a SHA1 hash starts with 5731 (or contain it) > it seems. > An undocumented feature: artifact symbols which look like integers are

[fossil-users] strange `fossil diff ' behaviour

hi, I have stumbled over the following observation when performing these action within a checkout of of `fossil' itself: fossil timeline -v -n 10 | grep 5731 ## --> no hit fossil diff -r 5731 ## lots of output (related to which revision???) hopefully not a stupid question: what's going