Re: [fossil-users] commits from host A sometimes not seen on B
On 21 August 2013 05:25, Donny Ward donnyjw...@gmail.com 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. I once submitted a ticket about it here: http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext ... That sounds familiar. For the record, let me say I never (ever) make branches; all work here is done on trunk. The ticket you mention is 'fixed' stating a workaround like I did here; I'm not sure that is how it should be. (Not that reopening the ticket magically fixes the problem, but you give detailed and probably useful information there.) Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[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 on here? can someone confirm this? there is no checkin with a SHA1 hash starts with 5731 (or contain it) it seems. fossil version 1.26 [09c2cf3e58] j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] strange `fossil diff ' behaviour
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 contain it) it seems. An undocumented feature: artifact symbols which look like integers are treated as record IDs. -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 12:58 PM, Stephan Beal sgb...@googlemail.comwrote: 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 contain it) it seems. An undocumented feature: artifact symbols which look like integers are treated as record IDs. http://fossil-scm.org/index.html/artifact/7cf572cae550c67e4de994d1ff99560badabe8af?ln=252-264 -- - 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] strange `fossil diff ' behaviour
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com 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 contain it) it seems. An undocumented feature: artifact symbols which look like integers are treated as record IDs. 0. intentionally undocumented or did nobody manage to add it to the manpages? 1. I don't hope this happens with priority (i.e. only if the integer is not the leading segment of a valid checkin hash)? 2. for the layman: what exactly is the record ID? obviously it's not simply the chronological checkin number? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com 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 with priority (i.e. only if the integer is not the leading segment of a valid checkin hash)? See the 2nd and 3rd lines - those ensure that it only matches a whole number. 2. for the layman: what exactly is the record ID? obviously it's not simply the chronological checkin number? Almost - it's the db entry record ID (blob.rid table/field). They tend to be chronological, but philosophically speeking that's not guaranteed (except that autoincrementing basically guarantees it). -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal sgb...@googlemail.com 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 sgb...@googlemail.com 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. Intentional might be too strong of a word here. I think j. van den hoff is correct that internal record ideas should not surprise the user in this way. The logic needs to be that record ids are use ONLY if there is no SHA1 hash with a prefix that matches the input. 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. 1. I don't hope this happens with priority (i.e. only if the integer is not the leading segment of a valid checkin hash)? See the 2nd and 3rd lines - those ensure that it only matches a whole number. 2. for the layman: what exactly is the record ID? obviously it's not simply the chronological checkin number? Almost - it's the db entry record ID (blob.rid table/field). They tend to be chronological, but philosophically speeking that's not guaranteed (except that autoincrementing basically guarantees it). -- - 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 -- 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
[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 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?): fossil set ignore-glob .* fossil set ignore-glob *.css But *this one* works with both versions: fossil set ignore-glob *.php My conclusion is this must have something to do with command line argument globing (so I assume it has something to do with ticket [8ca2aae391], but I can't be sure), and argument separation, b/c it seems to work if the wildcard expands to a single directory entry. I switched back to version 1.24 b/c of this, but I'm hoping this can be fixed. Best regards, Zoc ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 7:48 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal sgb...@googlemail.comwrote: 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 sgb...@googlemail.com 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. Intentional might be too strong of a word here. 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:? I think j. van den hoff is correct that internal record ideas should not surprise the user in this way. The logic needs to be that record ids are use ONLY if there is no SHA1 hash with a prefix that matches the input. 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. 1. I don't hope this happens with priority (i.e. only if the integer is not the leading segment of a valid checkin hash)? See the 2nd and 3rd lines - those ensure that it only matches a whole number. 2. for the layman: what exactly is the record ID? obviously it's not simply the chronological checkin number? Almost - it's the db entry record ID (blob.rid table/field). They tend to be chronological, but philosophically speeking that's not guaranteed (except that autoincrementing basically guarantees it). -- - 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 -- D. Richard Hipp d...@sqlite.org -- 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] Command-line wildcards
On Wed, Aug 21, 2013 at 7:49 AM, fossilscm@xoxy.net 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 1st place?) Oh well... My findings: 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?): fossil set ignore-glob .* fossil set ignore-glob *.css Did you try quoting to prevent the command-line wildcard expansion? fossil set ignore-glob .* But *this one* works with both versions: fossil set ignore-glob *.php My conclusion is this must have something to do with command line argument globing (so I assume it has something to do with ticket [8ca2aae391], but I can't be sure), and argument separation, b/c it seems to work if the wildcard expands to a single directory entry. I switched back to version 1.24 b/c of this, but I'm hoping this can be fixed. Best regards, Zoc ___ 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] 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, fossilscm@xoxy.net 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 1st place?) Oh well... My findings: 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?): fossil set ignore-glob .* fossil set ignore-glob *.css Did you try quoting to prevent the command-line wildcard expansion? fossil set ignore-glob .* But *this one* works with both versions: fossil set ignore-glob *.php My conclusion is this must have something to do with command line argument globing (so I assume it has something to do with ticket [8ca2aae391], but I can't be sure), and argument separation, b/c it seems to work if the wildcard expands to a single directory entry. I switched back to version 1.24 b/c of this, but I'm hoping this can be fixed. Best regards, Zoc ___ 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 ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 1:48 PM, Richard Hipp d...@sqlite.org 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 - i'll add that tonight. -- - 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] Command-line wildcards
2013/8/21 fossilscm@xoxy.net: 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. Regards, Jan Nijtmans ___ 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] 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 codeb...@inbox.lv 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 commit contains two checksums: one is the checksum of the content of the checkin manifest (basically: the formal list of changes, but not the changes themselves, similar to a PGP signature). The second one is a checksum of the names/sizes/content of each file in the commit manifest (basically: each file that changed). Fossil ignores/skips over/elides the PGP wrapper for purposes of checksums. and If that's true I would say if you verify any signed commit (and again it's not clear how multiple files are handled unless every file is signed individually) The signing happens at the commit level, and a commit contains N files. If I understood what you wrote, the checkin manifest is some kind of meta data about the commit and the second one above is *one* checksum on the list [a file of?] of names/sizes/content of each file in the commit manifest? Which also sounds sortof like metadata and data combined. From a digital signature view I would say each user component of a checkin (each source file and everything I want to include in this commit) ought to be signed individually if only for the practical reason there isn't any meaningful alternative. If I got what you wrote then the signature you have today is on meta-data, which is derived from the commit components. That seems to be a suboptimal or even wrong way to employ digital signing because nobody is responsible for this, it's done in software, on some metaobject that I have no direct control over- as if the key owner is assigning perfect trust to fossil to do the right thing. That means fossil is authenticating the checkin, which is not useful or meaningful. Digital signing means I certify that I wrote this. This thing itself, and not something derived from it. It might be clumsier for fossil, but it seems to me that if you choose to employ digital signatures on a project they ought to be required and verified individually on all components of a checkin. This will have to be a detached signature in the case of binaries. And if I can guess what you're thinking it's probably not worth it I might be inclined to agree. It is something that doesn't scale when a commit is at a higher level than one piece of source code. This is heavy-duty stuff to be used when you need to know with virtual certainty that person X updated a specific file. If you don't need to know that then this is overkill and a lot of work. If you do need to know it there isn't any other practical way to accomplish it. If all this is accurate then I don't understand how it works in practice today. Is fossil signing metadata? Who is signing it? then you should not have to do anything further, maybe not even note that it's PGP signed. The PGP signing is about authenticating that some user X is really the guy who did this update. Once that has been established it goes into the repo and nothing more has to happen. There's the problem for the current architecture: when it goes in the repo. Let's say for a second that one of the signed commits in Fossil's repo is currently invalid. Now we add this feature. The next time fossil is rebuilt, it would have to reject that commit, which would break the whole rebuild, effectively leaving us with a repo we can't upgrade because PGP decided we shouldn't. From a practical standpoint it's exactly the same as a bad checksum. Whatever you do in that case is what you should do for a bad PGP signature. Saying PGP decided we shouldn't is the same as saying your SHA1 algorithm decided you shouldn't. This stuff is heavily used and if you're going to use it you have to rely on it. If you can't rely on it you shouldn't be using it in the first place. Any code can break. In practice, we don't see that gpg or PGP signatures have bugs any more than SHAx implementations do. Fossil has no useful recovery strategy there other than to not let you rebuild the db (==update its schema to a newer version, which also rebuilds all derivable/calculable data contained in the repo). i think flag and accept would be the best Fossil could sanely do. What i can envision is, assuming validation has hypothetically been added: a) show yellow/green/red in the timeline, and something similar in CLI b) a 'pgp' command which takes a list of UUIDs to verify. But i don't think Fossil is capable of rejecting failures without seriously endangering backwards compatibility in the case of an age-old signature (==predating this feature) which is invalid. Maybe it could, or maybe it could offer an option/flag to allow failed sigs or not. i'm not in any way, shape, or form a cryptographer, i'm just thinking out loud here :/. I hear
Re: [fossil-users] Command-line wildcards
2013/8/21 Jan Nijtmans jan.nijtm...@gmail.com: 2013/8/21 fossilscm@xoxy.net: 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. Oops, I was too fast without reading the message well. Correct answer is: There are two possible ways: - Use fossil ui, go to Admin-Settings and modify the settings there. - Quote it with single quotes. Regards, Jan Nijtmans ___ 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] Command-line wildcards
On Wed, Aug 21, 2013 at 1:49 PM, fossilscm@xoxy.net 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 1st place?) Oh well... To cut down on bug db junk. Fossil is of a size where any pressing issues are covered directly on the mailing lists. We rarely go through the tickets and things get lost that way (it would be fair to call this a cultural issue, but there has so far been no pressing need for change there). If someone brings it up on the list first, the chances of the bug getting addressed skyrocket from near 0 to... well, above 0 ;). -- - 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] 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.jan.nijtmans#gmail@ob.0sg.net wrote: 2013/8/21 fossilscm@xoxy.net: 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. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] 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 fossilscm@xoxy.netwrote: @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.jan.nijtmans#gmail@ob.0sg.net wrote: 2013/8/21 fossilscm@xoxy.net: 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. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] 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: $ fossil set ignore-glob '*.css' $ fossil set ignore-glob ignore-glob (local) '*.css' The single quotes become part of the property value. (Not sure if this stops fossil from processing it correctly though.) Be that as it may, both the fossil ui thing and the single quote thing can IMO only be workarounds, not the real deal; the latter b/c numerous other scripts (of mine, but I'd assume of other people too) depend on a normal argument passing. On Wed, Aug 21, 2013 at 1:59 PM, Jan Nijtmans - jan.nijtm...@gmail.com fossilscm.zoc.1c6a0fe4b8.jan.nijtmans#gmail@ob.0sg.net wrote: 2013/8/21 Jan Nijtmans jan.nijtm...@gmail.com: 2013/8/21 fossilscm@xoxy.net: 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. Oops, I was too fast without reading the message well. Correct answer is: There are two possible ways: - Use fossil ui, go to Admin-Settings and modify the settings there. - Quote it with single quotes. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] commit signing
On Wed, Aug 21, 2013 at 1:58 PM, John Long codeb...@inbox.lv 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 second one above is *one* checksum on the list [a file of?] of names/sizes/content of each file in the commit manifest? Which also sounds sortof like metadata and data combined. Exactly - the second (R-card) checksum is a checksum of a _part of_ the manifest _plus_ the data referenced by that part of the manifest. If any byte gets corrupted anywhere, the whole thing fails on multiple levels. From a digital signature view I would say each user component of a checkin (each source file and everything I want to include in this commit) ought to be signed individually if only for the practical reason there isn't any meaningful alternative. i can't speak to this, i can only say how fossil currently does it - it signs the manifest (the list/metadata) but not the files. Because the manifest holds the SHA1 hashes of all files in the commit, a change to any of them is detectable, which (in theory) means that if the manifest is signed and untampered, so are the files it refers to by SHA1 (a.k.a. UUID in fossil terminology). If I got what you wrote then the signature you have today is on meta-data, which is derived from the commit components. That seems to be a suboptimal or even wrong way to employ digital signing because nobody is responsible for this, it's done in software, on some metaobject that I have no direct control over- as if the key owner is assigning perfect trust to fossil to do the right thing. That means fossil is authenticating the checkin, which is not useful or meaningful. i can't say - i only happen to know these code bits because i recently ported them from fossil(1) to fossil(3). The exact significance (or not) of them... i've left most of that thinking for later on (or others more qualified in the topics, as you clear are regarding cryptography!). Digital signing means I certify that I wrote this. This thing itself, and not something derived from it. Being one of those who doesn't place all that much worth on digital security (that's going to bite me one day), i would almost suggest that the different is splitting hairs in this case because the SHA1s of the files we are indirectly signing are just as valid as any PGP signature we might wrap around them. We then sign the SHA1s, in effect, as opposed to the content. Obviously, SHA1 can be attacked, but i have yet to see it happen. binaries. And if I can guess what you're thinking it's probably not worth it I might be inclined to agree. Almost - i was thinking, there are probably people out there for whom this would be worth it, but i can't personally name one ;). If all this is accurate then I don't understand how it works in practice today. Is fossil signing metadata? Who is signing it? Fossil can sign it at commit-time (it's an option) on the client side, but in the main repo it is seldom (if ever) still used. i recently saw it used on another repo, but AFAIK none of the fossil devs currently signs their commits. If Fossil were a higher-profile platform that might need to change, but so far we're a fairly small/manageable team and we haven't had (thankfully!) any bad experiences which have forced us into more rigid behaviours. So basically fossil doesn't sign: it gives the client the option to sign and then just carries that signature around in the metadata without placing any meaning on it. There's the problem for the current architecture: when it goes in the repo. Let's say for a second that one of the signed commits in Fossil's repo is currently invalid. Now we add this feature. The next time fossil is rebuilt, it would have to reject that commit, which would break the whole rebuild, effectively leaving us with a repo we can't upgrade because PGP decided we shouldn't. From a practical standpoint it's exactly the same as a bad checksum. Exactly - a much more concise description than mine. Whatever you do in that case is what you should do for a bad PGP signature. Saying PGP decided we shouldn't is the same as saying your SHA1 algorithm decided you shouldn't. This stuff is heavily used and if you're going to use it you have to rely on it. If you can't rely on it you shouldn't be using it in the first place. Any code can break. In practice, we don't see that gpg or PGP signatures have bugs any more than SHAx implementations do. Correct, but because the PGPs we have inserted to far have _never_ been validated, it might happen that there are one or more which are not valid. Fossil only does a very rough syntactic check on the envelope, so it's completely possible to insert PGP signatures with hand-crafted junk in them. I hear you. But accepting a bad signature
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 receive emails from threads I am participating in? On Wed, Aug 21, 2013 at 1:59 PM, Stephan Beal - sgb...@googlemail.com fossilscm.zoc.4adf3ee589.sgbeal#googlemail@ob.0sg.net wrote: On Wed, Aug 21, 2013 at 1:49 PM, fossilscm@xoxy.net 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 1st place?) Oh well... To cut down on bug db junk. Fossil is of a size where any pressing issues are covered directly on the mailing lists. We rarely go through the tickets and things get lost that way (it would be fair to call this a cultural issue, but there has so far been no pressing need for change there). If someone brings it up on the list first, the chances of the bug getting addressed skyrocket from near 0 to... well, above 0 ;). -- - 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 ___ 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] Command-line wildcards
On Wed, Aug 21, 2013 at 2:31 PM, fossilscm@xoxy.net 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 arrive in the app _without_ the quotes). Using *.css MIGHT be equivalent: most shells will not expand the wildcard unless there is a match, and if there is no match then they leave it intact (bash has a configuration option to change this and replace a non-matching wildcard with an empty string). The main difference is that in Unix the shell does a surprising amount of pre-processing of the CLI args before passing them on the app, meaning that all apps get a consistent view of CLI args. Windows, OTOH leaves the developer to do it all himself. The dogfood here is without a doubt the Windows shell. 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 War) since last millennium - i can't suggest much of anything in that regard except maybe to find something more... well, more. :) -- - 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] 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 sgb...@googlemail.com wrote: On Wed, Aug 21, 2013 at 2:31 PM, fossilscm@xoxy.net 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 arrive in the app _without_ the quotes). Using *.css MIGHT be equivalent: most shells will not expand the wildcard unless there is a match, and if there is no match then they leave it intact (bash has a configuration option to change this and replace a non-matching wildcard with an empty string). The main difference is that in Unix the shell does a surprising amount of pre-processing of the CLI args before passing them on the app, meaning that all apps get a consistent view of CLI args. Windows, OTOH leaves the developer to do it all himself. The dogfood here is without a doubt the Windows shell. 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 War) since last millennium - i can't suggest much of anything in that regard except maybe to find something more... well, more. :) -- - 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 ___ 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] Command-line wildcards
On Wed, Aug 21, 2013 at 8:31 AM, fossilscm@xoxy.net 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 sort of thing that we want to preserve in the permanent record of a repository. Hence we have chosen to filter through the mailing list first. This is a judgement call. You can run your project differently, if you desire. Wiki and ticketing are used extensively in self-hosting Fossil - dogfood is eaten - just not by anonymous. -- 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] 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' doesn't show the recent commit 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline' 7) on host C: do more work, and commit changes 8) on host 'S': 'fossil up'; now all recent commits are seen Perhaps relevant info: - autosync=1 on both sides - host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd - both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386 - fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC - fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC Just to add some anecdotal data to this . . . I've seen this behavior recently as well, in very similar circumstances. The major difference has been that both clients have autosync turned off, and do a manual sync before hacking on code, and either a pull before pushing commits or a manual sync. Running fossil update after a sync or pull that brings in changes that, in turn, do not show up in the client's checkout directory does not solve the problem, if I recall correctly. It has only happened a couple of times, and both times was fixed by a merge on one side or the other or a reclone. Unfortunately, I have not been able to determine whether any particular pattern of using manual sync or pull has an effect on this. Note that, as I said, it has not happened much, so I have not had much opportunity to identify the conditions specific to the manifestation of the problem with any certainty, apart from what I have mentioned above, which is why I had not composed a question myself about this issue yet. This situation concerns us because the workflow we use may lead to problems if a failure of Fossil to properly deliver commits leads to new code being added in a non-merged way without developers noticing. The server is running Fossil v1.26 (from ports) on FreeBSD 9.0 amd64, one client is running Fossil v1.26 (from ports) on FreeBSD 9.1 amd64, and the other client is running an unknown version of Fossil (from packages) on Arch Linux amd64, I believe, though I will check on the Fossil version when that developer is available and double-check the installed OS with him as well, and share that information if it is deemed relevant. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] 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
*/
int wmain(int argc, wchar_t **argv)
#else
+int_CRT_glob = 0;
int main(int argc, char **argv)
+
#endif
{
const char *zCmdName = unknown;
int idx;
int rc;
I did not test this with the 64bit version of MinGW. Using an unquoted * in
this case still works as expected.
Mark
On Wed, Aug 21, 2013 at 2:42 PM, Mark Janssen mpc.jans...@gmail.com wrote:
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 sgb...@googlemail.comwrote:
On Wed, Aug 21, 2013 at 2:31 PM, fossilscm@xoxy.net 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 arrive in the app _without_ the quotes). Using
*.css MIGHT be equivalent: most shells will not expand the wildcard unless
there is a match, and if there is no match then they leave it intact (bash
has a configuration option to change this and replace a non-matching
wildcard with an empty string).
The main difference is that in Unix the shell does a surprising amount of
pre-processing of the CLI args before passing them on the app, meaning that
all apps get a consistent view of CLI args. Windows, OTOH leaves the
developer to do it all himself.
The dogfood here is without a doubt the Windows shell.
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 War) since last millennium - i can't suggest much of anything
in that regard except maybe to find something more... well, more.
:)
--
- 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
___
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] 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 donnyjw...@gmail.com 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. I once submitted a ticket about it here: http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext ... 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 made, so add one to the numbers for this condition of the problem arising. The ticket you mention is 'fixed' stating a workaround like I did here; I'm not sure that is how it should be. (Not that reopening the ticket magically fixes the problem, but you give detailed and probably useful information there.) Indeed. The fix is in the behavior of one person's repository, and not in the intermittently manifesting issue with the operation of Fossil itself. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] Command-line wildcards
On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen mpc.jans...@gmail.com 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 Unix behaviour, anyway.) -- - 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] 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 sgb...@googlemail.com wrote: On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen mpc.jans...@gmail.comwrote: 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 Unix behaviour, anyway.) -- - 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 ___ 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] 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 mpc.jans...@gmail.com wrote: Yes, for example fossil add * will still do the right thing. On Wed, Aug 21, 2013 at 2:51 PM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen mpc.jans...@gmail.comwrote: 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 Unix behaviour, anyway.) -- - 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 ___ 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] commits from host A sometimes not seen on B
On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin c...@apotheon.net 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 made, so add one to the numbers for this condition of the problem arising. The sync protocol for Fossil ( http://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki) pays no attention to check-ins or branching or tags or any other structure in the repository. The sync logic looks at the repository as an unordered bag of artifacts and it tries to make both participating repositories have the same set of artifacts. It treats the artifacts as opaque binary blobs. So, whatever this bug is, I'm guessing it does not have anything to do with branching. FWIW, the --verily option to fossil sync causes both participates to send igot cards for every artifact they hold (which can be tens or hundreds of thousands of artifacts). This seems to be sufficient to get both sides back into sync with one another. The downside is that with hundreds of thousands of artifacts, sending all those igot cards takes a lot of network traffic. The bug must be in one of the shortcuts by which Fossil normally avoids sending its complete set of igot cards. -- 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] Command-line wildcards
2013/8/21 Mark Janssen mpc.jans...@gmail.com: 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: http://www.fossil-scm.org/fossil/info/8ca2aae391 And: http://www.fossil-scm.org/fossil/info/8205c01cd4 Different people have different expectations. Regards, Jan Nijtmans ___ 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] 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 War) since last millennium - i can't suggest much of anything in that regard except maybe to find something more... well, more. Uh? My question was about the mailman mailing list?!? How is that related to Windows? In any other respect, I take your response as rather... snobbish. Not sure how much of it represent the fossil position, but If fossil does not *want* to support windows, then it should remove the windows edition instead of so obviously looking down on its (I'd suppose many) windows users. But thanks anyway. :-( On Wed, Aug 21, 2013 at 2:36 PM, Stephan Beal - sgb...@googlemail.com fossilscm.zoc.4adf3ee589.sgbeal#googlemail@ob.0sg.net wrote: On Wed, Aug 21, 2013 at 2:31 PM, fossilscm@xoxy.net 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 arrive in the app _without_ the quotes). Using *.css MIGHT be equivalent: most shells will not expand the wildcard unless there is a match, and if there is no match then they leave it intact (bash has a configuration option to change this and replace a non-matching wildcard with an empty string). The main difference is that in Unix the shell does a surprising amount of pre-processing of the CLI args before passing them on the app, meaning that all apps get a consistent view of CLI args. Windows, OTOH leaves the developer to do it all himself. The dogfood here is without a doubt the Windows shell. 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 War) since last millennium - i can't suggest much of anything in that regard except maybe to find something more... well, more. :) -- - 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 ___ 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] 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 than that of a particular checkout. Steve On Wed, Aug 21, 2013 at 2:03 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin c...@apotheon.net 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 made, so add one to the numbers for this condition of the problem arising. The sync protocol for Fossil ( http://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki) pays no attention to check-ins or branching or tags or any other structure in the repository. The sync logic looks at the repository as an unordered bag of artifacts and it tries to make both participating repositories have the same set of artifacts. It treats the artifacts as opaque binary blobs. So, whatever this bug is, I'm guessing it does not have anything to do with branching. FWIW, the --verily option to fossil sync causes both participates to send igot cards for every artifact they hold (which can be tens or hundreds of thousands of artifacts). This seems to be sufficient to get both sides back into sync with one another. The downside is that with hundreds of thousands of artifacts, sending all those igot cards takes a lot of network traffic. The bug must be in one of the shortcuts by which Fossil normally avoids sending its complete set of igot cards. -- 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 ___ 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] 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.zoc.aac92b9903.mpc.janssen#gmail@ob.0sg.net wrote: 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 mpc.jans...@gmail.comwrote: Yes, for example fossil add * will still do the right thing. On Wed, Aug 21, 2013 at 2:51 PM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen mpc.jans...@gmail.comwrote: 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 Unix behaviour, anyway.) -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] strange `fossil diff ' behaviour
On Wed, 21 Aug 2013 13:25:50 +0200, Stephan Beal sgb...@googlemail.com wrote: On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com 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 with priority (i.e. only if the integer is not the leading segment of a valid checkin hash)? See the 2nd and 3rd lines - those ensure that it only matches a whole number. 2. for the layman: what exactly is the record ID? obviously it's not simply the chronological checkin number? Almost - it's the db entry record ID (blob.rid table/field). They tend to be chronological, but philosophically speeking that's not guaranteed (except that autoincrementing basically guarantees it). philosophical issues aside: does that mean that with the current implementation (and probably forever) the record IDs are actually simply enumerating checkins (or everything (wiki, tickets, etc.)?). because if they are, I'd come back to an old wish of mine, namely to make these numbers visible in the timeline output (at least on the command line) and to accept them (probably with priority over SHA1 spec.) instead of the hashes in all commands requiring revision specification(s). this wrapper: http://fossil.0branch.com/fsl/timeline?y=ci (designed by marc simpson) does this already to some extent (in the `dresden' branch only), i.e. displays timeline entries with added chronological revision numbers (checkins only) derived from simply counting all entries in the complete timeline and makes these numbers understood by `diff' ,`merge', `up'. that's what I use right now, but having the rev. numbers provided by fossil itself would be really appreciated. (NB: pleas don't explain again to me that these numbers are not necessarily unique across clones -- I understand that -- and that they are thus EVIL (they are not) ;-)) j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Command-line wildcards
On Wed, Aug 21, 2013 at 9:23 AM, fossilscm@xoxy.net 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 prebuild binaries was compiled with MinGW and the other with MSVC. -- 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] Command-line wildcards
On Wed, Aug 21, 2013 at 3:18 PM, fossilscm@xoxy.net 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 how much of it represent the fossil position, but If Nothing i say should be interpreted as an official statement unless Richard echoes me ;). i'm just a minion here (though admittedly a loud one. ;) Feel free to ignore anything i say and i won't take it personally. i apologize if it came across as snobbish (i did - i admit that). i was following the wildcard thread and i get really sick of people blaming fossil for Windows' broken CLI handling and filename/getenv encoding, which puts me in a snarky state of mind. My apologies for that. fossil does not *want* to support windows, then it should remove the windows edition instead of so obviously looking down on its (I'd suppose many) windows users. But thanks anyway. :-( Fossil wants to - _i_ don't want to ;). Plenty of people here have put in a great deal of effort to work around Windows' deficiencies (and yes, they are deficiencies). As a good example, the filename handling code - all of it is there only to support OS(es) which do their own thing regarding encoding of filenames. -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 1:50 PM, Richard Hipp d...@sqlite.org 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/fossil/fossil$ ./fossil info rid:22135 uuid: 884a765abdce9f475961c5887d4e33c78c542232 2013-08-20 14:07:58 UTC parent: d632a50e2a06c76b5f3432c2c9920110088fb43d 2013-08-20 12:57:48 UTC tags: timeline-pgp-marker comment: Added a link to the pgp-signed note. Not happy with how it turns out, but it is proof-of-concept. (user: stephan) stephan@tiny:~/cvs/fossil/fossil$ ./fossil info 22135 Fossil internal error: no such object: 22135 -- - 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] 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 sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 3:25 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
philosophical issues aside:
does that mean that with the current implementation (and probably
forever) the record
IDs are actually simply enumerating checkins (or everything (wiki,
tickets, etc.)?).
Yes, but don't get the idea that...
because if they are, I'd come back to an old wish of mine, namely to
make
these numbers visible in the
timeline output (at least on the command line) and to accept them
(probably with priority over SHA1 spec.)
instead of the hashes in all commands requiring revision
specification(s).
... they are guaranteed to be stable. The IDs are doled out by the db
system and it is not required to make them sequential. If record number N
is deleted, the db engine is (AFAIK) free to re-allocate that record ID
later. The external APIs/users should _never_ rely on these numbers.
(designed by marc simpson) does this already to some extent (in the
`dresden' branch only), i.e. displays
timeline entries with added chronological revision numbers (checkins
only)
derived from simply counting all entries in the
complete timeline and makes these numbers understood by `diff' ,`merge',
`up'. that's what I use
right now, but having the rev. numbers provided by fossil itself would
be
really appreciated.
The rid (record id) values could be used in such a way, but they are
an
implementation detail which i personally would not like to see
used/leaked
in client code. Any such use would be taking advantage of details which
could change tomorrow (i LIKE to change undefined behaviours just to
ensure
that no client code relies on them).
with due respect, that's too dogmatic for my taste. and it's also a
question what you decide to include
into the specification and what not, right? I understand that there is no
_need_
to enforce that the RIDs are sequential
but there seems to be no need either to change the de facto behavior and
make non-sequential RIDs a reality. meaning I don't see why the current
behavior could not be declared will not change with 1.x releases (or
never), so that one _could_ rely on it.
(NB: pleas don't explain again to me that these numbers are not
necessarily unique across clones -- I understand that -- and that they
are
thus EVIL (they are not) ;-))
i didn't say EVIL, i said UNRELIABLE, which is, in effect, much the same
thing. Unreliability is worse than no reliability.
so you did not say but _mean_ EVIL which is what matters and which is a
position I happen to not share (admittedly without knowing anything about
the inner workings of fossil):
after all, end-user experience ultimately decides about
success/dissemination of any software I would say and providing (AFAICS
without any adverse side effects) the end user with the ability to do
fossil `diff -r 123 --to 124' instead of `diff -r {unmemorizable sha1 code
goes here} --too {unmemorizable sha1 code goes here}' to get a diff
between successive checkins, e.g., would improve usability on the command
line w/o question.
if it is not going to happen, since nobody is willing (or has the time
resources) to do it, that's a pity in my view, but as so often a valid
decision on the side of the developers. arguing against the principal
desirability is another matter and here I really disagree.
and yes, one can work around this with scripts (that's why I'm happy that
marc simpson provided his `fsl' in the first place), but the very
existence of workarounds tells something about the existing CLI, namely
that shortcomings are of a degree that people really go to the trouble of
writing not-quite trivial scripts (something I have never observed with
`hg' and `svn'). nothing of this deters me from using fossil but still...
best
joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
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 detail is exposed
to clients, it makes changing the detail later much harder without
upsetting people. The more internal details which can be hidden, the more
resistant end-users are to changes in internal behaviour. It's about
long-term maintainability, not about end-user convenience.
into the specification and what not. I understand that there is no _need_
to enforce that the RIDs are sequential
but there seems to be no need either to change the de facto behavior and
make non-sequential RIDs a reality. meaning I don't see why the current
behavior could not be declared will not change with 1.x releases (or
never), so that one _could_ rely on it.
DVCSs cannot, by their very nature, portably support sequential numbers.
This topic has been beaten to death by brains much larger than mine.
so you did not say but _mean_ EVIL which is what matters and which is a
position I happen to not share (admittedly without knowing anything about
the inner workings of fossil):
Then submit a patch :).
after all, end-user experience ultimately decides about
success/dissemination of any software I would say and providing
Becoming a dominant DVCS is not, as far as i'm aware, a project goal.
(AFAICS without any adverse side effects) the end user with the ability to
do fossil `diff -r 123 --to 124' instead of `diff -r {unmemorizable sha1
code goes here} --too {unmemorizable sha1 code goes here}' to get a diff
between successive checkins, e.g., would improve usability on the command
line w/o question.
Then figure out how to do with a DVCS and tell us how. The RIDs are NOT
something we (the royal we, meaning software developers in general) do
not want to expose - they are implementation details and exposing them
leads, long term, to grief and suffering. Dogmatic? Absolutely. But it's a
hard-earned fact of life software developers eventually learn to accept and
account for.
and yes, one can work around this with scripts (that's why I'm happy that
marc simpson provided his `fsl' in the first place), but the very existence
of workarounds tells something about the existing CLI, namely that
shortcomings are of a degree that people really go to the trouble of
writing not-quite trivial scripts (something I have never observed with
`hg' and `svn'). nothing of this deters me from using fossil but still...
Give me an algorithm which works and does not expose app-internal details
to the end users/scripts and i will commit to implementing it.
--
- 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com 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 numbers as per Mercurial. That is, while my revision 5 needn't match yours (e.g., autosync is off and we've both committed), we can each still perform local operations using these numbers (e.g., diff -r 3:5). ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson m...@0branch.com wrote: On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com 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 numbers as per Mercurial. That is, while my revision 5 needn't match yours (e.g., autosync is off and we've both committed), we can each still perform local operations using these numbers (e.g., diff -r 3:5). My argument at the time against that still stands, though: those numbers could be changed by any given modification to either the filesystem or the db. Which means that 3:5 might, in 3 seconds, have a different meaning. It's an unreliable mechanism which, after painstakingly implemented, will eventually result in a mail with a tried to diff using -r 3:5 and i got a diff of 2:4 instead. Fossil developers cannot possibly know what goes on on your local system and will not in any way be able to help with 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. -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote: On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com 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 numbers as per Mercurial. That is, while my revision 5 needn't match yours (e.g., autosync is off and we've both committed), we can each still perform local operations using these numbers (e.g., diff -r 3:5). Please note that the internal record IDs are increasing, but not sequential. In the self-hosting Fossil repository at www.fossil-scm.org, the first check-in is 65, the second is 72, the third is 74, and fourth is 85, and so forth. So even if the record IDs were exposed, they would not give you sequential numbers as you get with mercurial. I fully support Stephan's insistence on not exposing record IDs unnecessarily. It is, in theory, possible to support repository-specific sequential version numbers, such as one finds in mercurial. This would require a new database table to maps the sequential numbers into record IDs and some code additions in various places to populate and use that new table. If you think that having repository-specific sequential version numbers is a good thing (I do not) then you are welcomed to argue your case for that enhancement. But, unfortunately, exposing record IDs is not quite the same thing. -- 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
[fossil-users] Control artifact types [Was: Minor new feature: comments when closing/re-opening]
2013/8/19 Stephan Beal sgb...@googlemail.com: 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 both fossil(1) and fossil(3). 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 cards allowed in Manifests are a super-set of the cards allowed in Control artifacts. I found one example which shows that fossil's method is not 100% correct (== assuming the documentation is correct). According to the documentation, this artifact should be valid: http://fossil-scm.org/index.html/info/2a4e4cf03ec12f99 In stead, fossil handles this one as a valid Control artifact. It cannot be a Control artifact because it has self-referential T-cards. It has all mandatory cards for a Manifest, so it should be handled as one. I added a check which determines that this artifact is not a valid Control artifact here: http://www.fossil-scm.org/index.html/info/13161f39aa but it looks like that's not enough to determine the type of this artifact correctly. Ongoing... Regards, Jan Nijtmans ___ 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] 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 sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
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 detail is
exposed
to clients, it makes changing the detail later much harder without
upsetting people. The more internal details which can be hidden, the more
resistant end-users are to changes in internal behaviour. It's about
long-term maintainability, not about end-user convenience.
you are stating/constructing a non-existent principal conflict between
long-term maintainability and end-user convenience here
into the specification and what not. I understand that there is no
_need_
to enforce that the RIDs are sequential
but there seems to be no need either to change the de facto behavior and
make non-sequential RIDs a reality. meaning I don't see why the current
behavior could not be declared will not change with 1.x releases (or
never), so that one _could_ rely on it.
DVCSs cannot, by their very nature, portably support sequential numbers.
This topic has been beaten to death by brains much larger than mine.
which is not relevant, I'm only talking about my local clone and how to
interact with it.
so you did not say but _mean_ EVIL which is what matters and which is a
position I happen to not share (admittedly without knowing anything
about
the inner workings of fossil):
Then submit a patch :).
yes sure, or write my own DVCS. not _that_ realistic at it stands.
after all, end-user experience ultimately decides about
success/dissemination of any software I would say and providing
Becoming a dominant DVCS is not, as far as i'm aware, a project goal.
neither is staying a niche application with a sub-optimal CLI.
(AFAICS without any adverse side effects) the end user with the ability
to
do fossil `diff -r 123 --to 124' instead of `diff -r {unmemorizable sha1
code goes here} --too {unmemorizable sha1 code goes here}' to get a diff
between successive checkins, e.g., would improve usability on the
command
line w/o question.
Then figure out how to do with a DVCS and tell us how. The RIDs are NOT
something we (the royal we, meaning software developers in general) do
not want to expose - they are implementation details and exposing them
leads, long term, to grief and suffering. Dogmatic? Absolutely. But it's
a
hard-earned fact of life software developers eventually learn to accept
and
account for.
you must be talking about different issues not about the possibility of
enumerating checkins in a way that the user can access this info.
and yes, one can work around this with scripts (that's why I'm happy that
marc simpson provided his `fsl' in the first place), but the very
existence
of workarounds tells something about the existing CLI, namely that
shortcomings are of a degree that people really go to the trouble of
writing not-quite trivial scripts (something I have never observed with
`hg' and `svn'). nothing of this deters me from using fossil but
still...
Give me an algorithm which works and does not expose app-internal details
to the end users/scripts and i will commit to implementing it.
I really think we have a principal mis-understanding: the only think I
would like to have is access to the _locally_ valid ordinal numbers
(chronological enumeration) of the checkins. there is no ambiguity here,
whatsoever. as far as I understand you, the current RIDs essentially are
just these numbers? in the next step it would be perfect if `fossil' would
support these numbers as alternative (possibly to be prioritized in case
of names clash (rev num 1234 vs. sha1 hash 1234xxx)) to the hashes in all
the commands requiring revision info.
that's all.
regards,
joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] Control artifact types [Was: Minor new feature: comments when closing/re-opening]
On Wed, Aug 21, 2013 at 5:13 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 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 cards allowed in Manifests are a super-set of the cards allowed in Control artifacts. I found one example which shows that fossil's method is not 100% correct (== assuming the documentation is correct). According to the documentation, this artifact should be valid: http://fossil-scm.org/index.html/info/2a4e4cf03ec12f99 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/53a6ffa8e3f2c499cc2531d3201b98f1bc32a0dc?ln=2901-2933 i run that each time i see a card for as long as the manifest has an undefined type. Once we know the type, each card which comes in passes through an is the card legal for artifact type xyz check. That approach might work well for you. In stead, fossil handles this one as a valid Control artifact. It cannot be a Control artifact because it has self-referential T-cards. It has all mandatory cards for a Manifest, so it should be handled as one. i still need to port in that particular check (i saw your commit on it). -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 5:10 PM, Stephan Beal sgb...@googlemail.com 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 realistic example: fossil status ... get my list of numbers... now my editor auto-saves some file i had opened but not yet saved. fossil ci 1-3 oops. -- - 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] 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...@lists.fossil-scm.org] On Behalf Of Stephan Beal Sent: Tuesday, August 20, 2013 11:45 To: Fossil SCM user's discussion Subject: Re: [fossil-users] getting fossil timeline to show time offsets On Tue, Aug 20, 2013 at 6:25 PM, j. van den hoff veedeeh...@googlemail.commailto:veedeeh...@googlemail.com wrote: On Tue, 20 Aug 2013 17:59:11 +0200, Benedikt Ahrens benedikt.ahr...@gmx.netmailto:benedikt.ahr...@gmx.net wrote: Hello, the fossil timeline command shows UTC time rather than observing the system setting (UTC+02:00, in my case). Is there anything I can do to change this? you can switch off UTC (so that it uses local time) in the web interface (admin - timeline). don't know whether there is a command line way to do this. in parallel i've been looking for one and haven't found it. i assume there isn't one. TODO += add 'localtime' config setting (boolean) IIRC the internal infrastructure is there, it just seems to be missing from the CLI settings comment (?). -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 5:09 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote: On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com 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 numbers as per Mercurial. That is, while my revision 5 needn't match yours (e.g., autosync is off and we've both committed), we can each still perform local operations using these numbers (e.g., diff -r 3:5). Please note that the internal record IDs are increasing, but not sequential. In the self-hosting Fossil repository at www.fossil-scm.org, the first check-in is 65, the second is 72, the third is 74, and fourth is 85, and so forth. So even if the record IDs were exposed, they would not give you sequential numbers as you get with mercurial. I fully support Stephan's insistence on not exposing record IDs unnecessarily. It is, in theory, possible to support repository-specific sequential version numbers, such as one finds in mercurial. This would require a new database table to maps the sequential numbers into record IDs and some code additions in various places to populate and use that new table. If you think that having repository-specific sequential version numbers is a good thing (I do not) then you are welcomed to argue your case for that enhancement. But, unfortunately, exposing record IDs is not quite the same thing. 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 tickets I am working on. When working with fossil I always have to look up the uuid. ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 11:26 AM, Mark Janssen mpc.jans...@gmail.comwrote: 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 tickets I am working on. When working with fossil I always have to look up the uuid. But then if you push your tickets to a collaborator he will end up with different sequential ticket numbers. So he sends you an email talking about bug 12 and you look at bug 12 and see a completely different ticket. Confusion ensues. The bottom line is that you cannot have sequential numbers without a central authority issuing those numbers. And the whole idea behind a *distributed* system is that there is no central authority. There are advantages and disadvantages to being distributed. The lack of sequential numbers is one of the disadvantages. -- 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 5:26 PM, Mark Janssen mpc.jans...@gmail.com 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 tickets I am working on. When working with fossil I always have to look up the uuid. But ticket discussions assume non-local use (b/c others need those ticket numbers, too), and that's where sequential numbering flies out the window in a DVCS. i'd LOVE to see it solved, but all the discussions i've read on the topic, and my derived understanding, is that it cannot be done in the DVCS model. If someone can suggest an implementation which is neither subject to misuse, exposes no internal data, and is not too terribly intrusive, i will commit to implementing it (as a reward to you guys who are (understandably) sick of hearing me say it can't be done! ;). -- - 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] 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 # diff between current and 2 commits ago on this branch fossil info trunk~2 # info of second commit tagged trunk (if this makes sense with how fossil uses tags) meaning diff over last two checkins on this branch. etc. [1] http://fossil-scm.org/index.html/doc/trunk/www/checkin_names.wiki ___ 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] 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 or by only one maintainer then the tags would be stable. Perhaps a clean up mode would add/remove tags if there were collisions due to two parallel runs of the script. For very little overhead (I assume having lots of tags is a negligible burden on fossil) those folks wanting an easy to use and sequential way to identify nodes would be made mostly happy. The more I think about it the more I like this. Even though I'm very happy with the hex node keys I'd like to be able to think about commits in terms of human friendly names that convey temporal relationship and I could live with the risk of mutability of tags. A mechanism to disallow pushing of same named tags would make this stronger as those using fossil in a star topology would have the central fossil disallow conflicting tags pushed from external. I mention this feature knowing full well that this may not be possible/easy for the same reasons that preventing branches from syncing is not easily doable. On Wed, Aug 21, 2013 at 8:14 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Aug 21, 2013 at 5:10 PM, Stephan Beal sgb...@googlemail.comwrote: 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 realistic example: fossil status ... get my list of numbers... now my editor auto-saves some file i had opened but not yet saved. fossil ci 1-3 oops. -- - 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] strange `fossil diff ' behaviour
On Wed, 21 Aug 2013 17:09:52 +0200, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote: On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com 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 numbers as per Mercurial. That is, while my revision 5 needn't match yours (e.g., autosync is off and we've both committed), we can each still perform local operations using these numbers (e.g., diff -r 3:5). Please note that the internal record IDs are increasing, but not sequential. In the self-hosting Fossil repository at www.fossil-scm.org, the first check-in is 65, the second is 72, the third is 74, and fourth is 85, and so forth. So even if the record IDs were exposed, they would not give you sequential numbers as you get with mercurial. I fully support Stephan's insistence on not exposing record IDs unnecessarily. It is, in theory, possible to support repository-specific sequential version numbers, such as one finds in mercurial. This would require a new database table to maps the sequential numbers into record IDs and some code additions in various places to populate and use that new table. If you think that having repository-specific sequential version numbers is a good thing (I do not) then you are welcomed to argue your case for that enhancement. But, unfortunately, exposing record IDs is not quite the same thing. 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 this in this thread and already some month ago in a different one. I just can only reiterate: -- locally there is no ambiguity/no problem -- revnums are more human-friendly in different ways (notably for the not-so-seldem diffs of successive revisions). something like 72:[3ac24d1cd2] 2013-01-11 j dresden tidy up. 71:[ced1483e1b] 2013-01-10 j dresden small fix. 70:[b7f21c3555] 2013-01-10 j dresden minor tidy up. 69:[34844683fd] 2013-01-10 j dresden small fix. 68:[b84e704411] 2013-01-10 j dresden bug fix (skipping of single word remaini 67:[abc0e49ac5] 2013-01-10 j dresden tentative addition of chronological revi 66:[4038632842] 2013-01-08 marc trunk Simplify the prompt regexp (no need to e 65:[d183a47466] 2013-01-06 j dresden restore usual meaning of line in `time 64:[de9dfa49ae] 2013-01-06 j dresden added new proc `reformTimeline' for refo 63:[6c76c5ec8d] 2013-01-05 j dresden fixed comment sytnax bug. 62:[ba3a1b7d98] 2013-01-01 j dresden small fix. 61:[38deb932f7] 2013-01-01 j dresden merged from trunk. as a timeline (or in this case: finfo -b) display plus support of this in fossil allows to do, e.g. fossil diff -r 69 --to 70 (and the convential `-r 69:70' syntax would still be nicer) instead of fossil diff -r 3484 --to b7f2, which might be seen as a minor convenience but looking up/copying/typing the correct sha1 hashes is a continuous nuisance that never stops. so the whole/sole point is a more comfortable CLI. in the mentioned script at http://fossil.0branch.com/fsl/timeline?y=ci I did (in the dresden branch) essentially what you propose as an additional map in the database: go through the complete timeline and build an associative array whose keys are the hashes and whose values are the numbers (and from that derive a reverse one that allows to look up the hashes when the revnums are given). the script than simply replaces the revnums by the hashes in the constructed fossil call. so I'm not sure what further arguments (that have not been stated repeatedly) I could give so if you could get around to implementing that map as a first step that would be great (at least I could then avoid parsing the whole timeline output to set up that map myself in the `fsl' script ;-)). best, j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] strange `fossil diff ' behaviour
On Wed, 21 Aug 2013 17:10:59 +0200, Stephan Beal sgb...@googlemail.com wrote: On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson m...@0branch.com wrote: On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com 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 numbers as per Mercurial. That is, while my revision 5 needn't match yours (e.g., autosync is off and we've both committed), we can each still perform local operations using these numbers (e.g., diff -r 3:5). My argument at the time against that still stands, though: those numbers could be changed by any given modification to either the filesystem or the db. Which means that 3:5 might, in 3 seconds, have a different meaning. It's an unreliable mechanism which, after painstakingly implemented, will eventually result in a mail with a tried to diff using -r 3:5 and i got a diff of 2:4 instead. Fossil developers cannot possibly know what goes on on your local system and will not in any way be able to help with such problems if they cannot be reproduced easily. i could see it being halfway I understand it would be completely reliable for diff up merge etc. for `commit' I don't see any usage of either revnums or hashes to be specified by the user? and fossil internally _of_course_ will always use the hashes. 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. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 5:37 PM, j. van den hoff veedeeh...@googlemail.comwrote: 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 this in this thread and already some month ago in a different one. I just can only reiterate: Just to clarify: i FULLY agree with you that it would be really cool, but my personality dictates that the pragmatics take precedence over the usability/comfort :/. i'm very much a function over form kind of guy. Because of that, i argue strongly against the feature, but not because i dislike the idea itself. i'd like to see it done, but not at a high cost (code/maintenance). so if you could get around to implementing that map as a first step that would be great (at least I could then avoid parsing the whole timeline output to set up that map myself in the `fsl' script ;-)). Side-note... the library interface will allow clients to add this sort of supplemental metadata/functionality, and will eventually provide enough support that, for example, it becomes a simple matter to write one's own commit function which sits between the user and the lib-level one (which, as you've pointed out, works with uuids/rids). Reminder to self: a rebuild drops all tables it doesn't recognize as being part of its holy infrastructure. We might want a heuristic which avoids tables with a certain prefix, e.g. client_%. -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 5:43 PM, Stephan Beal sgb...@googlemail.com 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 collaborators would not go amiss :). The only requirement for commit access is that a license waiver be on file with DRH. i.e. you must be a Fossil contributor so that i can keep the code license-clean. http://fossil.wanderinghorse.net/repos/f2/index.cgi/timeline -- - 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] 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.1.1 whatever) -- 'distance to revision' numbers a la git(?) are going only halfway and while `diff -r -2' might be convenient this could be the next step (and would be _really_ easy with a wrapper once the local revnums are there). -- local revnums a la `hg' are _really_ helpful and make life on the command line easier. arguing that they can't work really is nonsense. arguing that they are _not_ helpful as an alternative to sha1 hash specification is everybody's own opinion. most end-users probably would not agree and prefer the revnums (just as me) I suspect. -- locally there cannot be _any_ ambiguity of what is meant by `checkin n is the next one after (n-1)' (n=1, 0 being the initial checkin). its simply defined by the date when it occurs (after (n-1), before (n+1)). you obviously agree and understand that anyway, since you state that a further map in the database could provide that info. -- anything beyond these revnums (and ultimately their support by all commands) is _not_ what I'm talking about and it also confuses the current discussion in my view. best j. On Wed, 21 Aug 2013 17:09:52 +0200, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote: On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com 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 numbers as per Mercurial. That is, while my revision 5 needn't match yours (e.g., autosync is off and we've both committed), we can each still perform local operations using these numbers (e.g., diff -r 3:5). Please note that the internal record IDs are increasing, but not sequential. In the self-hosting Fossil repository at www.fossil-scm.org, the first check-in is 65, the second is 72, the third is 74, and fourth is 85, and so forth. So even if the record IDs were exposed, they would not give you sequential numbers as you get with mercurial. I fully support Stephan's insistence on not exposing record IDs unnecessarily. It is, in theory, possible to support repository-specific sequential version numbers, such as one finds in mercurial. This would require a new database table to maps the sequential numbers into record IDs and some code additions in various places to populate and use that new table. If you think that having repository-specific sequential version numbers is a good thing (I do not) then you are welcomed to argue your case for that enhancement. But, unfortunately, exposing record IDs is not quite the same thing. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[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 that's what this approach to Fossil is) i think that was about it? i _really_ liked the idea of the name (i've forgotten) which was a reference to a famously fake fossil, but i have been warned by one wiser than myself to avoid attempts at humorous names (his example being libiberty) and i tend to agree with him that such attempts eventually backfire in some way, shape, or form. (Side-note for history buffs: go look up the history of the mail reader Alpine's name, going all the way back to the first mail program (mail).) i'm still completely open for names but i keep finding myself writing libfossil and fossil(3) everywhere (i'm a doc fanatic), and would like to settle on one or the other relatively soon. Likewise, but of interest only to C coders, the main headers currently look like: #include fossil-scm/fossil.h // public API #include fossil-scm/fsl_internal.h // internal/pseudo-private API, will rename to fossil-internal.h eventually, for consistency If you C programmers feel strongly for some other convention, please speak up. You can peak at the code-related conventions here: http://fossil.wanderinghorse.net/repos/f2/doxygen/ (see the bottom half of that first page) and i am not emotionally attached to many of those, so feel free to suggest, e.g. better API name prefixes. The vast majority of things like that are trivial to refactor with a few lines of perl or sed (my main argument for keeping the repo db outside of the checkout dir, btw ;). Your opinions on the topic are much appreciated! -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 8:37 AM, Matt Welland estifo...@gmail.com 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 \.- v1.1.1 I think this is a really interesting idea. If the script worked incrementally and was run centrally or by only one maintainer then the tags would be stable. Perhaps a clean up mode would add/remove tags if there were collisions due to two parallel runs of the script. What if a repo had a blessed as the single source of revision numbers setting. That fossil, and only that fossil, would then add the system tag 'rev' or 'revnum' or something with the next available integer as the data to any new artifacts it sees that do not have a 'rev' tag, and the friendly revision numbers could flow out from that source of truth as a natural part of the syncing process. This could be conceptually just like the bgcolor tag -- I'm not sure what fossil does if there's a color conflict between repos but I'd bet the same logic would work here. And there really shouldn't be a need for conflict resolution outside of each repo protecting itself -- having two single sources of truth in the same graph is pretty much undefined by definition, right? I guess it would make sense for a blessed fossil to refuse to sync with another blessed fossil though :) For very little overhead (I assume having lots of tags is a negligible burden on fossil) those folks wanting an easy to use and sequential way to identify nodes would be made mostly happy. The more I think about it the more I like this. Even though I'm very happy with the hex node keys I'd like to be able to think about commits in terms of human friendly names that convey temporal relationship and I could live with the risk of mutability of tags. The win is apparent, I think. The disadvantages that I can see up front are; * Philosophically, the repos in a network are no longer all equal. Suspect this could be a bigger issue for some than for others. * The revisions are not strictly temporally ordered -- if a developer goes of to the Bahamas for two weeks and syncs when she gets home then all of her commits will be numbered when the blessed repo receives them. Strikes me as a good tradeoff for immutable revision numbers though -- and with autosync mode this should be a non-issue for most. * No revision number until you sync with the revision numbers source. Yuk, but I can't see what could possibly be done about this -- and I can imagine this as a huge source of list noise. * I have no idea how you would set up a topology other than a plain star / tree with this mechanism. What would happen with the canonical fossil-scm topology with three in the middle, for example? Someone commits to the wrong repo and all of a sudden it's sorry, no version number for you until the next round of synchronization in an hour? Anyways, I'm really just thinking out loud here. Themba ___ 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] 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 me, that fossil(1) is built on top of it. Whether or not that implication is common and / or appropriate I'll leave to you to negotiate with Richard. On Wed, Aug 21, 2013 at 10:11 AM, Stephan Beal sgb...@googlemail.comwrote: 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 that's what this approach to Fossil is) i think that was about it? i _really_ liked the idea of the name (i've forgotten) which was a reference to a famously fake fossil, but i have been warned by one wiser than myself to avoid attempts at humorous names (his example being libiberty) and i tend to agree with him that such attempts eventually backfire in some way, shape, or form. (Side-note for history buffs: go look up the history of the mail reader Alpine's name, going all the way back to the first mail program (mail).) i'm still completely open for names but i keep finding myself writing libfossil and fossil(3) everywhere (i'm a doc fanatic), and would like to settle on one or the other relatively soon. Likewise, but of interest only to C coders, the main headers currently look like: #include fossil-scm/fossil.h // public API #include fossil-scm/fsl_internal.h // internal/pseudo-private API, will rename to fossil-internal.h eventually, for consistency If you C programmers feel strongly for some other convention, please speak up. You can peak at the code-related conventions here: http://fossil.wanderinghorse.net/repos/f2/doxygen/ (see the bottom half of that first page) and i am not emotionally attached to many of those, so feel free to suggest, e.g. better API name prefixes. The vast majority of things like that are trivial to refactor with a few lines of perl or sed (my main argument for keeping the repo db outside of the checkout dir, btw ;). Your opinions on the topic are much appreciated! -- - 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 ___ 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] 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:revlistto=r:5746sbs=1 has an implementation of having repository local rev numbers for commits only. After updating fossil you'll need to do a fossil rebuild on the repo to fill the new table. 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. As you can see in the URL above the web UI also understands the new r:revnum syntax. This is not very well tested yet so use at your own risk. Mark ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen mpc.jans...@gmail.com 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://mpcjanssen.nl/fossil/fossil/artifact/01cd0cd7b2baee0ec438968994da3dfeead6c8a0?ln=347-356 it drops all non-core tables during rebuild, and revlist isn't in there. -- - 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] Bikeshedding opportunity: back to the topic of libfossil's name
On Wed, Aug 21, 2013 at 7:30 PM, Themba Fletcher themba.fletc...@gmail.comwrote: 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 official part of the fossil project and actually implies, at least to me, that fossil(1) is built on top of it. Whether or not that implication is common and / or appropriate I'll leave to you to negotiate with Richard. It also has the drawback of basically prohibiting the name (eventually) fossil v3. i also can't write -lfossil(3) (thought it would be funny). So, yeah, fossil(3) is nice but too impractical. :( -- - 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 7:36 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen mpc.jans...@gmail.comwrote: 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://mpcjanssen.nl/fossil/fossil/artifact/01cd0cd7b2baee0ec438968994da3dfeead6c8a0?ln=347-356 it drops all non-core tables during rebuild, and revlist isn't in there. That's on purpose, revlist is rebuilt when doing a fossil rebuild. This does mean that after a rebuild the short ids are probably different, but at the moment that's not really an issue. ___ 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] Bikeshedding opportunity: back to the topic of libfossil's name
On Wed, Aug 21, 2013 at 7:38 PM, Stephan Beal sgb...@googlemail.com 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 :/. 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 me, that fossil(1) is built on top of it. Whether or not that implication is common and / or appropriate I'll leave to you to negotiate with Richard. It also has the drawback of basically prohibiting the name (eventually) fossil v3. i also can't write -lfossil(3) (thought it would be funny). So, yeah, fossil(3) is nice but too impractical. :( -- - 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 +1 for libfossil. I hate it when libraries have smart names requiring me to google for the package name to install. ___ 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] 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 if memory serves), it does come accross... eccentric... to blame the OS (whichever it is) all of a sudden. 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 things (and make them work even on the crappiest of platforms ;-)). It wasn't my intention to judge or blame anyone or anything. On Wed, Aug 21, 2013 at 4:15 PM, Stephan Beal - sgb...@googlemail.com fossilscm.zoc.4adf3ee589.sgbeal#googlemail@ob.0sg.net wrote: On Wed, Aug 21, 2013 at 3:18 PM, fossilscm@xoxy.net 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 how much of it represent the fossil position, but If Nothing i say should be interpreted as an official statement unless Richard echoes me ;). i'm just a minion here (though admittedly a loud one. ;) Feel free to ignore anything i say and i won't take it personally. i apologize if it came across as snobbish (i did - i admit that). i was following the wildcard thread and i get really sick of people blaming fossil for Windows' broken CLI handling and filename/getenv encoding, which puts me in a snarky state of mind. My apologies for that. fossil does not *want* to support windows, then it should remove the windows edition instead of so obviously looking down on its (I'd suppose many) windows users. But thanks anyway. :-( Fossil wants to - _i_ don't want to ;). Plenty of people here have put in a great deal of effort to work around Windows' deficiencies (and yes, they are deficiencies). As a good example, the filename handling code - all of it is there only to support OS(es) which do their own thing regarding encoding of filenames. -- - 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 ___ 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] Bikeshedding opportunity: back to the topic of libfossil's name
On Wed, Aug 21, 2013 at 7:43 PM, Mark Janssen mpc.jans...@gmail.com 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 naming conflict (==cursor googling), there might potentially be one, which is why i eventually tagged -scm to the name. But, again, i'm not emotionally attached to that. In fact, the name doesn't have to contain fossil, but i assume that'd be easier for everyone. -- - 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] Command-line wildcards
On Wed, Aug 21, 2013 at 7:43 PM, fossilscm@xoxy.net 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 things (and make them work even on the crappiest of platforms ;-)). It wasn't my intention to judge or blame anyone or anything. You weren't at all out of line/over-sensitive. i took your post out of context and responded poorly to it (regardless of context). We very much appreciate any and all feedback, and a negative response from one of the devs (in this case me) does not in any way reflect on the feedback itself (well, except that Richard's decisions trump all others ;). -- - 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] 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 got every single update). I never had this issue (nor any other - kudos!) until 1.25. So if the used compiler varied randomly, the assumption doesn't hold - as I surely would have hit at least some MinGW-compiled version. On Wed, Aug 21, 2013 at 3:50 PM, Richard Hipp - d...@sqlite.org fossilscm.zoc.5877ad8d94.drh#sqlite@ob.0sg.net wrote: On Wed, Aug 21, 2013 at 9:23 AM, fossilscm@xoxy.net 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 prebuild binaries was compiled with MinGW and the other with MSVC. -- 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 ___ 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] strange `fossil diff ' behaviour
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com 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:revlistto=r:5746sbs=1 has an implementation of having repository local rev numbers for commits I my view revnums for checkins only is absolutely sufficient/just right. only. After updating fossil you'll need to do a fossil rebuild on the repo to fill the new table. 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. this is already quite nice. but ultimately I think the best solution would be to have the map revnum - sha1 as drh indicated where the revnums are just the chronological/auto-incremented index of the commits. j. As you can see in the URL above the web UI also understands the new r:revnum syntax. This is not very well tested yet so use at your own risk. Mark -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com 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:** revlistto=r:5746sbs=1http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlistto=r:5746sbs=1has an implementation of having repository local rev numbers for commits I my view revnums for checkins only is absolutely sufficient/just right. only. After updating fossil you'll need to do a fossil rebuild on the repo to fill the new table. 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. this is already quite nice. but ultimately I think the best solution would be to have the map revnum - sha1 as drh indicated where the revnums are just the chronological/auto-incremented index of the commits. 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 pass. This results in relatively monotomic ids which should be stable across consecutive rebuilds. One caveat, this could break horribly when delta manifests are present so use at your own risk. ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen mpc.jans...@gmail.comwrote: 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 pass. This results in relatively monotomic ids which should be stable across consecutive rebuilds. One caveat, this could break horribly when delta manifests are present so use at your own risk. Minor caveat: the rids might change across different clones of the same repo (the rids are never transported/synced, always computed locally) or (theoretically/maybe) when doing a rebuild with --vacuum or --randomize (though i'm speculating there). -- - 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] strange `fossil diff ' behaviour
On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen mpc.jans...@gmail.com wrote: On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com 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:** revlistto=r:5746sbs=1http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlistto=r:5746sbs=1has an implementation of having repository local rev numbers for commits I my view revnums for checkins only is absolutely sufficient/just right. only. After updating fossil you'll need to do a fossil rebuild on the repo to fill the new table. 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. this is already quite nice. but ultimately I think the best solution would be to have the map revnum - sha1 as drh indicated where the revnums are just the chronological/auto-incremented index of the commits. 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 pass. This results in relatively monotomic ids which should be stable across consecutive rebuilds. One caveat, this could break horribly when delta manifests are present so use at your own risk. 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 (be it locally or by a pull) or, rather, to assign a revnum in chronological order (i.e. the order in which `fossil timeline' displays the checkins). and then put that info in some table for the user to assess (and hopefully for the the fossil commands to accept instead of the hashes for identifying revisions). is there a principal technical difficulty in doing that? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] strange `fossil diff ' behaviour
On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal sgb...@googlemail.com wrote: On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen mpc.jans...@gmail.comwrote: 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 pass. This results in relatively monotomic ids which should be stable across consecutive rebuilds. One caveat, this could break horribly when delta manifests are present so use at your own risk. Minor caveat: the rids might change across different clones of the same repo (the rids are never transported/synced, always computed locally) or (theoretically/maybe) when doing a rebuild with --vacuum or --randomize (though i'm speculating there). but I believe this to be irrelevant: the whole point is to work with any given local clone/repo using revnums. there should not and need not be any expectation/requirement that these revnums are consistent across clones. it's all about interaction with the given local repo. as you repeatedly correctly stated it will lead to errors/confusion if people tell each other there is a problem in rev no. 123 and the other guys has a different interpretation of what revnum 123 is. empirically, that is not an issue I would say presuming that the `hg' field test is accepted as being statistically significant. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 11:22 PM, j. van den hoff veedeeh...@googlemail.com 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 been looking for use cases to justify adding a callback to the crosslinking phase, and you just provided a great one. While they arrive in the db is the key part - crosslinking is the step which does such processing when a manifest (checkin/change) arrives (or is rebuilt). i am toying with interfaces to allow clients to hook into that (and potentially abort the processing if in their view the artifact is undesirable). -- - 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] strange `fossil diff ' behaviour
On 21 Aug 2013 23:22, j. van den hoff veedeeh...@googlemail.com wrote: On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen mpc.jans...@gmail.com wrote: On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com 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:** revlistto=r:5746sbs=1 http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlistto=r:5746sbs=1 has an implementation of having repository local rev numbers for commits I my view revnums for checkins only is absolutely sufficient/just right. only. After updating fossil you'll need to do a fossil rebuild on the repo to fill the new table. 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. this is already quite nice. but ultimately I think the best solution would be to have the map revnum - sha1 as drh indicated where the revnums are just the chronological/auto-incremented index of the commits. 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 pass. This results in relatively monotomic ids which should be stable across consecutive rebuilds. One caveat, this could break horribly when delta manifests are present so use at your own risk. 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 (be it locally or by a pull) or, rather, to assign a revnum in chronological order (i.e. the order in which `fossil timeline' displays the checkins). and then put that info in some table for the user to assess (and hopefully for the the fossil commands to accept instead of the hashes for identifying revisions). is there a principal technical difficulty in doing that? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ Note that chronological and the order in which they get into the db are generally not equivalent in a DVCS. I think stability of the revs for a certain clone (with Stephan's caveats) is a good thing. There is no real reason why you can't initially generate them chronologically except that it would require more code in the rebuild command. Also if you pull older changes and rebuild revs will change. You should at least have enough now to try it out and see if it helps. ___ 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] 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 mpc.jans...@gmail.com 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 naming conflict (==cursor googling), there might potentially be one, which is why i eventually tagged -scm to the name. But, again, i'm not emotionally attached to that. In fact, the name doesn't have to contain fossil, but i assume that'd be easier for everyone. I definitely vote for the name libfossil. In fact, if you don't use it, I might have to encourage another Fossil library effort just so there's a libfossil that everyone will be able to find and remember. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 2:29 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal sgb...@googlemail.com wrote: On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen mpc.jans...@gmail.com 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=revlisthttp://mpcjanssen.nl/fossil/fossil/timeline?r=revlistI have changed this to a single pass. This results in relatively monotomic ids which should be stable across consecutive rebuilds. One caveat, this could break horribly when delta manifests are present so use at your own risk. Minor caveat: the rids might change across different clones of the same repo (the rids are never transported/synced, always computed locally) or (theoretically/maybe) when doing a rebuild with --vacuum or --randomize (though i'm speculating there). but I believe this to be irrelevant: the whole point is to work with any given local clone/repo using revnums. there should not and need not be any expectation/requirement that these revnums are consistent across clones. it's all about interaction with the given local repo. as you repeatedly correctly stated it will lead to errors/confusion if people tell each other there is a problem in rev no. 123 and the other guys has a different interpretation of what revnum 123 is. empirically, that is not an issue I would say presuming that the `hg' field test is accepted as being statistically significant. A request; if this mechanism gets implemented please ensure that a) displaying the numbers on the timeline is optional and b) off by default. In my experience ordinary users are very annoyed when things are different between different checkouts and having stable looking numbers that essentially can't be trusted is guaranteed to cause grief. For the very limited (too me) utility in these numbers the consequences of accidentally trusting them in the wrong context is far too high. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] 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 (after this very discussion). I also searched for libfsl, which appears to be claimed, I didn't look into what that project is. -bch On 8/21/13, Chad Perrin c...@apotheon.net wrote: On Wed, Aug 21, 2013 at 07:45:53PM +0200, Stephan Beal wrote: On Wed, Aug 21, 2013 at 7:43 PM, Mark Janssen mpc.jans...@gmail.com 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 naming conflict (==cursor googling), there might potentially be one, which is why i eventually tagged -scm to the name. But, again, i'm not emotionally attached to that. In fact, the name doesn't have to contain fossil, but i assume that'd be easier for everyone. I definitely vote for the name libfossil. In fact, if you don't use it, I might have to encourage another Fossil library effort just so there's a libfossil that everyone will be able to find and remember. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ 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] 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. Brief search yields https://github.com/paulfitz/libfossil as second hit (after this very discussion). I also searched for libfsl, which appears to be claimed, I didn't look into what that project is. As it happens, that GitHub hit appears to be someone's work on a library for Fossil SCM. Glancing across some of the code, it looks like it's a Ruby libfossil, so there'd be no practical namespace clash -- only a search engine namespace clash, which is a common case for libraries that do the same things in different languages anyway. I don't think that's much of an impediment. It currently has six commits, all from July, according to GitHub. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] 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/ another libfossil, though it too is pretty ugly looking. Brief search yields https://github.com/paulfitz/libfossil as second hit (after this very discussion). I also searched for libfsl, which appears to be claimed, I didn't look into what that project is. As it happens, that GitHub hit appears to be someone's work on a library for Fossil SCM. Glancing across some of the code, it looks like it's a Ruby libfossil, so there'd be no practical namespace clash -- only a search engine namespace clash, which is a common case for libraries that do the same things in different languages anyway. I don't think that's much of an impediment. It currently has six commits, all from July, according to GitHub. . . . and I found this on chisel: http://chiselapp.com/user/cutterpillow/repository/fossil-iOS/ There's a libfossil.cpp in the src directory of the source tree (requires anonymous login to view, naturally). That pretty much sums up my findings before web searches start devolving into stuff that doesn't really match, like ILU.lib - fossil-ice. It appears that all references to libfossil are, in fact, references to libraries related to Fossil SCM, specifically one for Ruby and one for iOS (unless my quick skim of each misinterpreted its purpose). I'd say the name should just be set in stone as libfossil now, and a mirror should be set up on GitHub to boost its search engine ranking a little bit (with a prominent mention of its canonical version control repository being elsewhere using Fossil itself, of course). While you're at it, if you're willing to bother, you could twit about it on Twitter and/or homestead the @libfossil name there. I wouldn't go so far as to recommend doing anything on Facebook, of course. That should about solve any potential namespace issues, by ensuring that other people checking to see if the name is taken will see your project and decide Yes, it does appear to be taken by an active project. I'll see if, at its current level of (in)completeness, it passes muster for inclusion in some of the Copyfree Initiative's lists (like copyfree licensed projects worthy of support or addition to the copyfree software listing), if you want to finally declare an official name for it as libfossil. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[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 out that just doing the fossil upd to refresh the repo changes its sha1 hash. Not helpful. So I tried to find a way to discern whether or not a repo was *really* different, and I hit upon the following. I think it would be nice if there were an easier way. Here is my fossilid script, which gives a single sha1 hash for the repo. Note that it checks both the config as well as the timeline for changes: if [ ! -f $1 ] then echo fossilid needs the name of the repository to 'id' exit 1 fi configsha=`fossil config export all -R $1 - | grep -v '^#'` logsha=`fossil timeline -n 10 -R $1` echo $configsha $logsha| fossil sha - | cut -d' ' -f1 -- Please use my GnuPG key AD29415D to communicate with me securely signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
