Re: [fossil-users] http --enforce-remote-user
On Sat, Oct 11, 2014 at 11:25 PM, David Mason dma...@ryerson.ca wrote: I'm still digging around in the code, trying to grok all this. Presumably there can be multiple manifests in a sync (or push) because there could be multiple commits without a push, and then they would all be presented at once. I don't suppose I'd be lucky enough that each manifest would be presented before the files involved in the commit or that all of one commit would be sent before the manifest of the next commit. No such luck. The artifacts are present in an arbitrary order. It is entirely possible that a push might involve multiple server round-trips and that the firrst server round-trip might send artifacts from later check-ins while the later round-trips send artifacts from earlier check-ins. A completely separate server process handles each round-trip. -- 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] http --enforce-remote-user
On 12 October 2014 06:06, Richard Hipp d...@sqlite.org wrote: No such luck. The artifacts are present in an arbitrary order. It is entirely possible that a push might involve multiple server round-trips and that the firrst server round-trip might send artifacts from later check-ins while the later round-trips send artifacts from earlier check- ins. A completely separate server process handles each round-trip. Ahhh... so you could have a client-server interaction that sent all the files from a commit and then the connection went down; and the server repo is perfectly OK, except that checkin doesn't yet exist, and then in another connection, the manifest gets delivered and cross-linking happens and the server repo now knows about the checking, so there really is no we're done with this commit point in the code other than (kind of incidentally) cross-linking. Let's try a more explicit example (but sticking to update only happening on the client and assuming no auto-sync for simplicity): Time 1: server client both have manifest 1 Time 2: user on client does a commit of file1 which puts file1 and manifest2 into client repo. Time 3: user does a push; file1 gets to server; connection fails before manifest2 gets there Time 4: user does a commit of file2, which puts file2 and manifest3 into client repo Time 5: user does push; manifest 3 gets to server; connection fails at this point looking at server you would only see manifest1 - no file1, no manifest3 (because it's dependent manifest2 isn't there) Time 6: new connection, file2 gets to server; connection fails still only manifest1 visible at server (i.e. no file1, no file2, and I presume if I did a rebuild at this point the artifacts for file1 and file2 would disappear). Time 7: new connection, manifest1 arrives, cross-link does its magic now manifest2 and manifest3 are visible at server. If I've got this right then: 1) this is very cool weird, but cool 2) I can't prevent the artifacts from going into the repo, so shunning is really the only option (I could remove them - ah, I could, but then they could get re-sent). 3) I can't shun the manifest (because essentially that client would never be able to commit again, even as the right id), but instead want to shun all the artifacts mentioned by the manifest, and maybe tag the manifest in some way so it shows up specially in the timeline. 4) I am thinking about recovery for valid commits that accidentally got committed with the wrong id, and I remember that there is a way to change the id associated with a commit, but I can't find it... any pointers? (The fallback to re-clone and re-commit would require the artifacts to be edited or un-shunned, so there's some work to do here...) 5) the only place I could auto-shun the invalid commit would be at cross-link time. Which sounds easier than I had been thinking, but I have one related question: If I commit version1 of a file, then version2, then version3 and then I shun version2, how does it get version1 and version3 since I thought files were stored as deltas and there would be an in-between version missing. Thanks, ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] http --enforce-remote-user
On Sun, Oct 12, 2014 at 10:53 AM, David Mason dma...@ryerson.ca wrote: On 12 October 2014 06:06, Richard Hipp d...@sqlite.org wrote: No such luck. The artifacts are present in an arbitrary order. It is entirely possible that a push might involve multiple server round-trips and that the firrst server round-trip might send artifacts from later check-ins while the later round-trips send artifacts from earlier check- ins. A completely separate server process handles each round-trip. Ahhh... so you could have a client-server interaction that sent all the files from a commit and then the connection went down; and the server repo is perfectly OK, except that checkin doesn't yet exist, and then in another connection, the manifest gets delivered and cross-linking happens and the server repo now knows about the checking, so there really is no we're done with this commit point in the code other than (kind of incidentally) cross-linking. Let's try a more explicit example (but sticking to update only happening on the client and assuming no auto-sync for simplicity): Time 1: server client both have manifest 1 Time 2: user on client does a commit of file1 which puts file1 and manifest2 into client repo. Time 3: user does a push; file1 gets to server; connection fails before manifest2 gets there Time 4: user does a commit of file2, which puts file2 and manifest3 into client repo Time 5: user does push; manifest 3 gets to server; connection fails at this point looking at server you would only see manifest1 - no file1, no manifest3 (because it's dependent manifest2 isn't there) I'll have to double-check, but I think manifest3 will still show up even if its parent manifest2 is still missing. Otherwise, your description seems spot on. Time 6: new connection, file2 gets to server; connection fails still only manifest1 visible at server (i.e. no file1, no file2, and I presume if I did a rebuild at this point the artifacts for file1 and file2 would disappear). Time 7: new connection, manifest1 arrives, cross-link does its magic now manifest2 and manifest3 are visible at server. If I've got this right then: 1) this is very cool weird, but cool 2) I can't prevent the artifacts from going into the repo, so shunning is really the only option (I could remove them - ah, I could, but then they could get re-sent). When you shun a file, it reports the SHA1 hash of that file in the shun table of the database, and thereafter refuses to accept it on a push. If the other side resends the file, it is silently discarded. 3) I can't shun the manifest (because essentially that client would never be able to commit again, even as the right id), but instead want to shun all the artifacts mentioned by the manifest, and maybe tag the manifest in some way so it shows up specially in the timeline. 4) I am thinking about recovery for valid commits that accidentally got committed with the wrong id, and I remember that there is a way to change the id associated with a commit, but I can't find it... any pointers? (The fallback to re-clone and re-commit would require the artifacts to be edited or un-shunned, so there's some work to do here...) When you say id are you talking about the branch that the check-in is part of? You can modify the branch of an existing check-in by going to the Edit page for that check-in and entering a new branch name. (The underlying mechanism is that a tag artifact is issued which modifies the displayed attributes of the original check-in. The original check-in is immutable and cannot be changed. But the added tag tells Fossil to display the check-in using a different branch.) We sometimes do this when we make a check-in by mistake. Here is one example of many: http://www.fossil-scm.org/fossil/timeline?c=01c83bfby=ci If you click on Mistake check-in ( www.fossil-scm.org/fossil/info/01c83bfbbfc), you can see that check-in originally went into trunk, then was moved over to the Mistake branch using the Edit screen. The edit also changed the check-in comment and background color. The edits were implemented by the tag seen at ( www.fossil-scm.org/fossil/info/42e170fbfed) 5) the only place I could auto-shun the invalid commit would be at cross-link time. Which sounds easier than I had been thinking, but I have one related question: If I commit version1 of a file, then version2, then version3 and then I shun version2, how does it get version1 and version3 since I thought files were stored as deltas and there would be an in-between version missing. The shun operation knows to undelta dependencies before it deletes the shunned file. I think http://www.fossil-scm.org/fossil/artifact/123f0542db2?ln=278 is the specific line of code that does that for you. The shun mechanism is really intended only to remove spam or illegal content. For honest mistakes, I think it is better to just move them off into a mistake branch. Thanks,
[fossil-users] Ordering ticket priority/severity
'Lo. Currently, if I do, in a ticket report: ORDER BY priority, severity I definitely get something ordered by priority and severity, but of course the ordering relation for both columns is lexicographical. That is, Important Critical because Critical appears earlier in the alphabet. That's pretty awful! Is there a recommended way to get a better ordering relation without having to mutilate the ticket system too much? M ___ 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] Ordering ticket priority/severity
I suppose the simplest solution would be to rename them to start with the required digit. Example: 1 Critical 2 Important -Original Message- From: org.fossil-scm.fossil-us...@io7m.com Sent: Monday, October 13, 2014 12:00 AM To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] Ordering ticket priority/severity 'Lo. Currently, if I do, in a ticket report: ORDER BY priority, severity I definitely get something ordered by priority and severity, but of course the ordering relation for both columns is lexicographical. That is, Important Critical because Critical appears earlier in the alphabet. That's pretty awful! Is there a recommended way to get a better ordering relation without having to mutilate the ticket system too much? M ___ 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] auto-sync before merge?
On Fri, Oct 10, 2014 at 8:01 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Oct 10, 2014 at 10:10 PM, Ross Berteig r...@cheshireeng.com wrote: Personally, I wouldn't expect that at all. The fossil merge command edits the currently open workspace based ... +1 The fossil update command on the other hand is not about making edits to the workspace that need to be ... +1 The autosync mechanism is fundamentally about keeping your repository synchronized with a remote repository, and has no effect on any open workspaces. +1 IMHO, the principle of least surprise should apply, and argues lightly against autosync on merge and is somewhat ambivalent about autosync on update. i like autosync on update - it's saved me from forks countless times. Here is a little more detail on the merge scenario that has confused me and others. NB// there are two general contexts for a merge, merge from a branch or merge from a node. When merging from a node there is no ambiguity and this conversation does not apply. However when merging from a branch there *is* ambiguity. The don't sync crowd sees the merge as applying to the tip of the branch as it is currently in your private database. The please sync crowd sees the merge as being from the latest on the tip whether I have it currently or not. Neither world view is intrinsically right but I do personally feel that if you intend to get a specific node (the don't sync crowd) then specify the node. To be consistent with the fossil closely-coupled model I feel that where possible fossil should autosync. For most of us bandwidth is not an issue and sync can always be turned off. Auto sync before merge and after tagging would have saved me a few support calls from confused users over the past few years :) Just my $0.02. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] http --enforce-remote-user
On 12 October 2014 13:59, Richard Hipp d...@sqlite.org wrote: The shun mechanism is really intended only to remove spam or illegal content. Yeah shunning is a really big stick. If I understand it correctly, if you ever shunned a 0-length file, you would never be able to commit a zero-length file again! I'm going to look at some of Richard's other comments a bit later.U ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ordering ticket priority/severity
Hi,
Below is one of my ticket report pages. I'm not entirely sure it's the best
approach but works fine for me. What it does is two selects. The inner
select classifies status, priority, severity and difficulty so then I can
order them appropriately. The outer select presents the data in human
readable way.
Note, that I added extra difficulty column to prioritize shorter tasks over
longer ones (you can easily remove that). Also, this report shows only
unclosed tickets assigned to the current user, again easy to change.
Hope it helps.
Cheers,
Jacek
===
SELECT
CASE WHEN status IN ('Open','Verified') THEN '#ffeedd'
WHEN status='Blocked' THEN '#ff'
WHEN status='Review' THEN '#e8e8e8'
WHEN status='Fixed' THEN '#cfffbd'
WHEN status='Tested' THEN '#bdffd6'
WHEN status='Deferred' THEN '#aabaff'
ELSE '#b8b8b8' END AS 'bgcolor',
substr(tkt_uuid,1,10) AS '#',
priority,
severity,
difficulty,
type,
status,
assigned_to,
subsystem,
CASE WHEN length(title) 60 THEN substr(title,0,57) || '...'
ELSE title END AS 'title'
FROM (
SELECT *,
CASE WHEN status IN ('Open','Verified','Blocked') THEN 0
WHEN status='Review' THEN 1
WHEN status='Fixed' THEN 2
WHEN status='Tested' THEN 3
WHEN status='Deferred' THEN 4
ELSE 5 END AS 'st',
CASE WHEN priority='Immediate' THEN 0
WHEN priority='High' THEN 1
WHEN priority='Medium' THEN 2
WHEN priority='Low' THEN 3
ELSE 4 END AS 'p',
CASE WHEN severity='Critical' THEN 0
WHEN severity='Severe' THEN 1
WHEN severity='Important' THEN 2
WHEN severity='Minor' THEN 3
ELSE 4 END AS 's',
CASE WHEN difficulty='Very_Easy_(0-15mins)' THEN 0
WHEN difficulty='Easy_(15min-2hr)' THEN 1
WHEN difficulty='Medium_(2hr-2days)' THEN 2
WHEN difficulty='Hard_(2days-2weeks)' THEN 3
ELSE 4 END AS 'd'
FROM ticket
WHERE status != 'Closed' AND (assigned_to = user() OR assigned_to =
'unassigned' OR assigned_to IS NULL)
ORDER BY st, p, s, d, tkt_mtime)
==
2014-10-12 22:00 GMT+01:00 org.fossil-scm.fossil-us...@io7m.com:
'Lo.
Currently, if I do, in a ticket report:
ORDER BY priority, severity
I definitely get something ordered by priority and severity, but of
course the ordering relation for both columns is lexicographical. That
is, Important Critical because Critical appears earlier in the
alphabet.
That's pretty awful! Is there a recommended way to get a better
ordering relation without having to mutilate the ticket system too
much?
M
___
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
