[fossil-users] File age in the tree view
I've hacked in a change so that the file tree viewer shows the age (how long ago the last change occurred) for each file. Or for directories it shows youngest age of all contented files and subdirectories. Example: https://www.fossil-scm.org/fossil/tree?ci=trunk I'm not yet convinced that this change is actually useful, though. It is still on a branch. Suggestions for improving it are welcomed. Things that might be improved: (1) Adjust the CSS so that the age is not all the way over on the right margin (2) Perhaps change the time display to use a common unit (days). Even as I was typing this, I realized that it is currently show the age from present. That's useful if you are looking at recent check-in, But if you are looking at the file tree for an ancient check-in, for example: https://www.fossil-scm.org/fossil/tree?ci=2008-01-01expand Then the age from present is much less useful. Perhaps the displayed age should be relative to the check-in that contains the files. Thoughts? -- 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] File age in the tree view
On Tue, Dec 16, 2014 at 5:42 PM, Richard Hipp d...@sqlite.org wrote:
I'm not yet convinced that this change is actually useful, though. It is
still on a branch. Suggestions for improving it are welcomed.
It's consistent with various hosting services, e.g. (IIRC) the old CVS/SVN
browser in Sourceforge and in github.
(1) Adjust the CSS so that the age is not all the way over on the
right margin
i rather like it there, but that's a matter for the CSS guys.
(2) Perhaps change the time display to use a common unit (days).
i have a code snippet somewhere around here which transforms to days,
months, minutes, etc. based on the degree of the timespan. It's not in
C, but it'd be easy to port.
Even as I was typing this, I realized that it is currently show the age
from present. That's useful if you are looking at recent check-in, But if
you are looking at the file tree for an ancient check-in, for example:
https://www.fossil-scm.org/fossil/tree?ci=2008-01-01expand
Then the age from present is much less useful. Perhaps the displayed
age should be relative to the check-in that contains the files. Thoughts?
Very interesting. Both could be useful, of course, in differing contexts.
FWIW, here's the snippet (JavaScript)...
/**
prettyTimestamp() turns a Unix Epoch timestamp in a human-friendly
form, e.g. 3 minutes ago or 7 days ago.
uts must be a Unix Epoch timestamp value. now may be a current time
timestamp, else the current time is used. When calling this in a loop,
pass your own now value (calculated outside the loop) to ensure that
there are no looping-related deviations in 'now' from one loop
to the next.
*/
ctor.prettyTimestamp = proto.prettyTimestamp = function( uts, now ){
var ce = arguments.callee;
if(!ce.secPerDay) {
ce.secPerDay = 60 * 60 * 24;
ce.secPerWeek = ce.secPerDay * 7;
ce.secPerMonth = 30 * ce.secPerDay;
ce.secPerYear = 365.25 * ce.secPerDay;
}
now = now || parseInt((new Date()).valueOf()/1000, 10);
var diff = now - uts;
//console.debug('now, diff',now,diff);
var n;
if( diff 0 ) return 'in the future';
else if( 0==diff ) return 'just now';
else if( diff 120 ){
n = diff;
return n+' second'+((n1)?'s':'')+' ago';
}
else if( diff 3600 ){
n = parseInt(diff/60, 10);
return n+' minute'+((n1)?'s':'')+' ago';
}
else if( diff = 3 * ce.secPerDay ){
n = parseInt(diff/3600, 10);
return n+' hour'+((n1)?'s':'')+' ago';
}
else if( diff = (4*ce.secPerYear) ){
n = parseInt(diff/ce.secPerYear, 10);
return n+' year'+((n1)?'s':'')+' ago';
}
else if( diff = (6*ce.secPerMonth) ){
n = parseInt(diff/ce.secPerMonth, 10);
return n+' month'+((n1)?'s':'')+' ago';
}
else if( diff = (4*ce.secPerWeek) ){
n = parseInt(diff/ce.secPerWeek, 10);
return n+' week'+((n1)?'s':'')+' ago';
}
else if( diff = ce.secPerDay ) {
n = parseInt(diff/ce.secPerDay, 10);
return n+' day'+((n1)?'s':'')+' ago';
}
};
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] crash w/ update, undo
What platform is it running on, and what version of Fossil have you got? ___ 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] crash w/ update, undo
NetBSD, [a0cc614326] -bch On 12/16/14, Warren Young w...@etr-usa.com wrote: What platform is it running on, and what version of Fossil have you got? ___ 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] File age in the tree view
On Tue, Dec 16, 2014 at 11:57 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Dec 16, 2014 at 5:42 PM, Richard Hipp d...@sqlite.org wrote: I'm not yet convinced that this change is actually useful, though. It is still on a branch. Suggestions for improving it are welcomed. It's consistent with various hosting services, e.g. (IIRC) the old CVS/SVN browser in Sourceforge and in github. (1) Adjust the CSS so that the age is not all the way over on the right margin i rather like it there, but that's a matter for the CSS guys. The problem was it was difficult to follow the line from the filename across to its age. We need some leading. Rather than that, I highlight the li element on mouse-over. See the latest on the website. Feedback from styling experts is welcomed. Even as I was typing this, I realized that it is currently show the age from present. That's useful if you are looking at recent check-in, But if you are looking at the file tree for an ancient check-in, for example: https://www.fossil-scm.org/fossil/tree?ci=2008-01-01expand Then the age from present is much less useful. Perhaps the displayed age should be relative to the check-in that contains the files. Thoughts? Very interesting. Both could be useful, of course, in differing contexts. The latest code now shows the time of the check-in and file times relative to the main check-in time, as a negative interval. I think that works better. But I'm still not happy with it, so it is still on a branch. There are also recent changes to the fileage page. See, for example: https://www.fossil-scm.org/fossil/fileage?name=trunk -- 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] File age in the tree view
On Tue, Dec 16, 2014 at 8:06 PM, Richard Hipp d...@sqlite.org wrote: The problem was it was difficult to follow the line from the filename across to its age. We need some leading. Rather than that, I highlight the li element on mouse-over. See the latest on the website. The mouseover is great :). The latest code now shows the time of the check-in and file times relative to the main check-in time, as a negative interval. I think that works better. i think i'd rather see something like the mouseover than the lines around: https://www.fossil-scm.org/fossil/fileage?name=trunk But I'm still not happy with it, so it is still on a branch. There are also recent changes to the fileage page. See, for example: https://www.fossil-scm.org/fossil/fileage?name=trunk i like how the tree's turned out, but the latter one took me a moment to figure out what was going on - that they are grouped by time offset. It also begs the question: how can we sort on that column (using JS) if we prettify the times? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] File age in the tree view
On Tue, Dec 16, 2014 at 5:42 PM, Richard Hipp d...@sqlite.org wrote: https://www.fossil-scm.org/fossil/tree?ci=2008-01-01expand you're obviously in an experimental mood, so here's something which clearly falls into the interesting to try out, but might turn out ugly category: add a heat map (like annotate) based on their ages. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] File age in the tree view
On Tue, Dec 16, 2014 at 2:11 PM, Stephan Beal sgb...@googlemail.com wrote: It also begs the question: how can we sort on that column (using JS) if we prettify the times? Maybe have the epoc time as a hidden field? Possibly less overhead that running the prettify JS in the browser, though that would be an option, too. ___ 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] File age in the tree view
On Tue, Dec 16, 2014 at 8:15 PM, Ron W ronw.m...@gmail.com wrote: On Tue, Dec 16, 2014 at 2:11 PM, Stephan Beal sgb...@googlemail.com wrote: It also begs the question: how can we sort on that column (using JS) if we prettify the times? Maybe have the epoc time as a hidden field? Possibly less overhead that running the prettify JS in the browser, though that would be an option, too. Or (lazier) have the time in ISO8601 format in a separate column and make that one sortable. (i'm thinking of the sort mechanism we already have in place. i think a hidden field might require extending that.) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] File age in the tree view
On Tue, Dec 16, 2014 at 2:11 PM, Stephan Beal sgb...@googlemail.com wrote:
The latest code now shows the time of the check-in and file times relative
to the main check-in time, as a negative interval. I think that works
better.
i think i'd rather see something like the mouseover than the lines around:
https://www.fossil-scm.org/fossil/fileage?name=trunk
That's all controlled by CSS so it is easy to customize. I added overrides
in the CSS for the canonical Fossil site. But I don't think I like them.
Take a look and see what you think.
The added rules are:
.fileage tr:hover {
background-color: #eee;
}
.fileage td {
vertical-align: top;
text-align: left;
padding-top: 1ex;
}
--
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] File age in the tree view
On Tue, Dec 16, 2014 at 8:27 PM, Richard Hipp d...@sqlite.org wrote: That's all controlled by CSS so it is easy to customize. I added overrides in the CSS for the canonical Fossil site. But I don't think I like them. Take a look and see what you think. Much nicer - toning down the lines makes all the difference. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] File age in the tree view
Hi Richard,
On 16 December 2014 at 11:27, Richard Hipp d...@sqlite.org wrote:
On Tue, Dec 16, 2014 at 2:11 PM, Stephan Beal sgb...@googlemail.com wrote:
The latest code now shows the time of the check-in and file times
relative to the main check-in time, as a negative interval. I think that
works better.
i think i'd rather see something like the mouseover than the lines around:
https://www.fossil-scm.org/fossil/fileage?name=trunk
That's all controlled by CSS so it is easy to customize. I added overrides
in the CSS for the canonical Fossil site. But I don't think I like them.
Take a look and see what you think.
Nice work!
Regarding sorting, yes, I think it would be nice if the time, files,
checkin were sortable fields.
The added rules are:
.fileage tr:hover {
background-color: #eee;
}
.fileage td {
vertical-align: top;
text-align: left;
padding-top: 1ex;
}
--
D. Richard Hipp
d...@sqlite.org
Best,
Jungle
--
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
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] File age in the tree view
On Tue, Dec 16, 2014 at 2:27 PM, Stephan Beal sgb...@googlemail.com wrote: (i'm thinking of the sort mechanism we already have in place. i think a hidden field might require extending that.) As best I understand, CSS can hide the extra column, just need to make sure the sort button for the age column refers to the invisible column as the sort key. ___ 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] File age in the tree view
On Tue, Dec 16, 2014 at 2:42 PM, Ron W ronw.m...@gmail.com wrote: On Tue, Dec 16, 2014 at 2:27 PM, Stephan Beal sgb...@googlemail.com wrote: (i'm thinking of the sort mechanism we already have in place. i think a hidden field might require extending that.) As best I understand, CSS can hide the extra column, just need to make sure the sort button for the age column refers to the invisible column as the sort key. Sorting is complicated. Only the subelements of a directory sort, not sub-subelements and not siblings of the subdirectory. Sorting by age is doable, but I think (at least for the initial implementation) it will be a new page request - in other words a server 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] File age in the tree view
Hi Richard, On 16 December 2014 at 11:52, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 16, 2014 at 2:42 PM, Ron W ronw.m...@gmail.com wrote: On Tue, Dec 16, 2014 at 2:27 PM, Stephan Beal sgb...@googlemail.com wrote: (i'm thinking of the sort mechanism we already have in place. i think a hidden field might require extending that.) As best I understand, CSS can hide the extra column, just need to make sure the sort button for the age column refers to the invisible column as the sort key. Sorting is complicated. Only the subelements of a directory sort, not sub-subelements and not siblings of the subdirectory. Sorting by age is doable, but I think (at least for the initial implementation) it will be a new page request - in other words a server round-trip. Take a look at this: http://tablesorter.com/docs/ Since the data that you want to sort is already on the page, I don't know what would need to be fetched to sort the list. -- D. Richard Hipp d...@sqlite.org Thanks, Jungle -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] File age in the tree view
On Tue, Dec 16, 2014 at 3:11 PM, jungle Boogie jungleboog...@gmail.com wrote: Sorting by age is doable, but I think (at least for the initial implementation) it will be a new page request - in other words a server round-trip. Take a look at this: http://tablesorter.com/docs/ Since the data that you want to sort is already on the page, I don't know what would need to be fetched to sort the list. I think tablesorter simply sorts a single linear table. That's not what is going on here. We are sorting a tree. That's a little different. The representation in HTML is as nested ul lists. You could maybe translated the nested ul lists in to a linear table (with a hidden depth column or something) but even then, the sorting is not as tablesorter does it because you only want to sort siblings within the same subdirectory. And you need to do the recursively. -- 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] File age in the tree view
On Tue, Dec 16, 2014 at 9:15 PM, Richard Hipp d...@sqlite.org wrote: I think tablesorter simply sorts a single linear table. That's not what is going on here. We are sorting a tree. That's a little different. i was only thinking of sorting for this one: https://www.fossil-scm.org/fossil/fileage?name=trunk the tree is a whole other can of worms. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] File age in the tree view
Hi Stephen, On 16 December 2014 at 12:20, Stephan Beal sgb...@googlemail.com wrote: On Tue, Dec 16, 2014 at 9:15 PM, Richard Hipp d...@sqlite.org wrote: I think tablesorter simply sorts a single linear table. That's not what is going on here. We are sorting a tree. That's a little different. i was only thinking of sorting for this one: https://www.fossil-scm.org/fossil/fileage?name=trunk the tree is a whole other can of worms. Right, I definitely can see how the trunk sort would be complicated. Additionally/alternatively, some search feature around the checkin link to help filter results better. (similar to control F in the browser but have it actually remove non-matched items). ;) -- - 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 best, jungle -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] File age in the tree view
On Tue, Dec 16, 2014 at 3:53 PM, jungle Boogie jungleboog...@gmail.com wrote: Additionally/alternatively, some search feature around the checkin link to help filter results better. (similar to control F in the browser but have it actually remove non-matched items). ;) You can add a query parameter re=REGEXP where REGEXP is a regular expression and it will only show the files that match that regular expression. So, for example, to see just the files (and their folders) that contain the letter a you would run: https://www.fossil-scm.org/fossil/tree?ci=trunkre=a But there is no web interface for this - you have to manually add the regular expression to the URL. Suggestions on how to make that more user-friendly are welcomed. Note that there are several query parameters on the timeline page that are likewise usually only accessible by manually adding them to the URL. Suggestions on a better interface there are also encouraged. -- 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] File age in the tree view
Hi Richard, On 16 December 2014 at 13:04, Richard Hipp d...@sqlite.org wrote: You can add a query parameter re=REGEXP where REGEXP is a regular expression and it will only show the files that match that regular expression. So, for example, to see just the files (and their folders) that contain the letter a you would run: https://www.fossil-scm.org/fossil/tree?ci=trunkre=a But there is no web interface for this - you have to manually add the regular expression to the URL. Suggestions on how to make that more user-friendly are welcomed. Does this work on the fileage that this thread is about? https://www.fossil-scm.org/fossil/fileage?name=trunkre=drh Seems to display the same results as https://www.fossil-scm.org/fossil/fileage?name=trunk Note that there are several query parameters on the timeline page that are likewise usually only accessible by manually adding them to the URL. Suggestions on a better interface there are also encouraged. I'm curious what unhiding here: https://www.fossil-scm.org/fossil/timeline actually does. https://www.fossil-scm.org/fossil/timeline 20 most recent timeline items Unhide: https://www.fossil-scm.org/fossil/timeline?n=20unhide 20 most recent timeline items From what I can tell, nothing is different except the grey buttons and the former displays the unhide, that's all. I just tried out the diff and at first I was expecting it to collapse but it's really very clever how it does the diffs! Maybe a legend of what the colors represent, unless it's obvious what the colors mean. -- D. Richard Hipp d...@sqlite.org Jungle -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] File age in the tree view
Thus said jungle Boogie on Tue, 16 Dec 2014 13:47:32 -0800: I'm curious what unhiding here: https://www.fossil-scm.org/fossil/timeline actually does. Try it here: https://www.fossil-scm.org/index.html/timeline?c=2014-11-06+21:46:01 Andy -- TAI64 timestamp: 40005490ab17 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Question on moving a repository (possible bug?)
Hello, I discovered something strange when moving repositories (I wanted to consolidate the location of some of mine). After some searching I came up with three possibilities for a repository relocation: 1) Simple moving the file and then updating the location both in the global configuration database as well as all checkout databases (which in my case would've been only one) via raw SQL commands. 2) Closing the checkout(s), moving the repository, and the re-opening the checkout(s). 3) Using the test-move-repository command (which I found in some of the archived list e-mails). Is that correct, or are there more ways? I considered variant 1 as too manual and too error-prone, and (despite the --force option for closing and the --keep option for re-opening) variant 2 has its disadvantages as well (like losing the undo history, the stash etc). Therefore I opted for variant 3. The move was successful in the end, but after issuing the command, the repository disappeared from the list of all repositories in the configuration database, i.e., it was not contained in the fossil all list output anymore. Luckily, after doing the first commit, it reappeared again… My questions here are: • Does this happen on purpose or is this a bug? For me it seems odd that the repository gets (temporarily) lost from the list of all repositories and thus excluded from all fossil all commands until being added again later. • If this is bug, why is it resolved by the first commit to the involved repository? My naive understanding is that a commit only affects the respective checkout database as well as of course the repository database itself, but not the global configuration database? In case this is indeed a bug, I can file a ticket (though the issue is not critical due to its exceptional nature). Thanks! ___ 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] File age in the tree view
There is now an mtime query parameter on the /tree page which orders the contents of each directory from mostly recently modified down to least recently. Example: https://www.fossil-scm.org/fossil/tree?ci=trunkmtime I still need to add controls so that the user can click to select the sort order. On Tue, Dec 16, 2014 at 4:58 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said jungle Boogie on Tue, 16 Dec 2014 13:47:32 -0800: I'm curious what unhiding here: https://www.fossil-scm.org/fossil/timeline actually does. Try it here: https://www.fossil-scm.org/index.html/timeline?c=2014-11-06+21:46:01 Andy -- TAI64 timestamp: 40005490ab17 ___ 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] Question on moving a repository (possible bug?)
Please try with trunk. On Tue, Dec 16, 2014 at 6:19 PM, Robert Engelhardt m...@robert-engelhardt.de wrote: Hello, I discovered something strange when moving repositories (I wanted to consolidate the location of some of mine). After some searching I came up with three possibilities for a repository relocation: 1) Simple moving the file and then updating the location both in the global configuration database as well as all checkout databases (which in my case would've been only one) via raw SQL commands. 2) Closing the checkout(s), moving the repository, and the re-opening the checkout(s). 3) Using the test-move-repository command (which I found in some of the archived list e-mails). Is that correct, or are there more ways? I considered variant 1 as too manual and too error-prone, and (despite the --force option for closing and the --keep option for re-opening) variant 2 has its disadvantages as well (like losing the undo history, the stash etc). Therefore I opted for variant 3. The move was successful in the end, but after issuing the command, the repository disappeared from the list of all repositories in the configuration database, i.e., it was not contained in the fossil all list output anymore. Luckily, after doing the first commit, it reappeared again… My questions here are: • Does this happen on purpose or is this a bug? For me it seems odd that the repository gets (temporarily) lost from the list of all repositories and thus excluded from all fossil all commands until being added again later. • If this is bug, why is it resolved by the first commit to the involved repository? My naive understanding is that a commit only affects the respective checkout database as well as of course the repository database itself, but not the global configuration database? In case this is indeed a bug, I can file a ticket (though the issue is not critical due to its exceptional nature). Thanks! ___ 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] Remove flat-view from menu? Was: File age in the tree view
Given the much improved tree-view functionality https://www.fossil-scm.org/fossil/tree?ci=trunkmtime Is there really any reason to keep the legacy Flat-View on the menu bar? https://www.fossil-scm.org/fossil/tree?ci=trunktype=flat I think the flat-view functionality should be preserved. (Who knows how many links to the flat-view exist on various wiki pages, tickets, and check-in comments.) But I don't see a reason to have it using up valuable menu-bar space. Comments? -- 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] Remove flat-view from menu? Was: File age in the tree view
On Wed, Dec 17, 2014 at 2:05 AM, Richard Hipp d...@sqlite.org wrote: Given the much improved tree-view functionality https://www.fossil-scm.org/fossil/tree?ci=trunkmtime Is there really any reason to keep the legacy Flat-View on the menu bar? https://www.fossil-scm.org/fossil/tree?ci=trunktype=flat I think the flat-view functionality should be preserved. (Who knows how many links to the flat-view exist on various wiki pages, tickets, and check-in comments.) But I don't see a reason to have it using up valuable menu-bar space. Actually... i use the flat view more often than not. That's probably just historical momentum (and the way my old menus are all set up). i wouldn't whine about loss of flat view, but also won't argue for its removal. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Remove flat-view from menu? Was: File age in the tree view
On Wed, Dec 17, 2014 at 2:16 AM, Stephan Beal sgb...@googlemail.com wrote: Actually... i use the flat view more often than not. That's probably just historical momentum (and the way my old menus are all set up). i wouldn't whine about loss of flat view, but also won't argue for its removal. flat mode meaning /dir instead of /tree. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Remove flat-view from menu? Was: File age in the tree view
On Tue, Dec 16, 2014 at 8:17 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Dec 17, 2014 at 2:16 AM, Stephan Beal sgb...@googlemail.com wrote: Actually... i use the flat view more often than not. That's probably just historical momentum (and the way my old menus are all set up). i wouldn't whine about loss of flat view, but also won't argue for its removal. flat mode meaning /dir instead of /tree. Yes. And remember, I'm not going to make /dir go away - I'm just wanting to take away its prominent links on the menu bar. The pages will all still be there for those who want them. But links to those pages won't clutter the screen for people who do not. -- - 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 -- 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] Remove flat-view from menu? Was: File age in the tree view
On Dec 16, 2014, at 6:05 PM, Richard Hipp d...@sqlite.org wrote: But I don't see a reason to have it using up valuable menu-bar space. Screen real estate is precious. Nuke that sucker. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Hungarian Notation Used in Fossil
I'm curious about the coding convention in fossil with respect to variable naming. It seems that the code follows something like the following convention: - integers have no prefix - strings have a z prefix e.g. zParam - pointers have a p prefix e.g. pSomething - function pointers have an x prefix e.g. xSaveAll What else is there? Is there any document that describes this convention? Perhaps also some rationale behind why this approach is used (hungarian notation being a somewhat controversial topic). Perhaps I'll even consolidate the info and contribute to the 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] Hungarian Notation Used in Fossil
On Tue, Dec 16, 2014 at 9:20 PM, Sean Woods s...@seanwoods.com wrote: I'm curious about the coding convention in fossil with respect to variable naming. It seems that the code follows something like the following convention: - integers have no prefix Sometime they have i for integer. Or sometimes they use n to mean number of. - strings have a z prefix e.g. zParam The z is for zero-terminated string. - pointers have a p prefix e.g. pSomething - function pointers have an x prefix e.g. xSaveAll Also a for array-of. And these get combined. So you see things like: char **azStrings; // An array of zero-terminated strings int nStrings; // number of strings That's the general idea. I have not been consistent in the use of these prefixes, nor have I required other people to use them. But they are useful at times. What else is there? Is there any document that describes this convention? Perhaps also some rationale behind why this approach is used (hungarian notation being a somewhat controversial topic). Perhaps I'll even consolidate the info and contribute to the wiki... ___ -- 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] Hungarian Notation Used in Fossil
Thus said Sean Woods on Tue, 16 Dec 2014 21:20:51 -0500: - integers have no prefix I believe there is an exception for when they represent something that may be ``boolean'' in which case: - boolean integers have a b prefix e.g. bBlame Andy -- TAI64 timestamp: 40005490ed29 ___ 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] Hungarian Notation Used in Fossil
On Wed, Dec 17, 2014 at 3:40 AM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Sean Woods on Tue, 16 Dec 2014 21:20:51 -0500: - integers have no prefix I believe there is an exception for when they represent something that may be ``boolean'' in which case: - boolean integers have a b prefix e.g. bBlame And sometimes 'f', for 'flag'. Occasionally one of the guys goes through and does a style fix patch for stuff like that, but overall we haven't ever much discussed it - we just generally try to follow the existing conventions (and don't always succeed). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Hungarian Notation Used in Fossil
I think the key thing is that symbol names convey what they are used for. Dr. Simonyi, nominal originator of Hungarian Notation, seems to agree in his paper about naming conventions. Microsoft has republished that paper: http://msdn.microsoft.com/en-us/library/aa260976%28v=vs.60%29.aspx My key take from that paper is could the same set of operations be meaningfully applied to the quantities in questions? If so, the types are thought to be the same. If there are operations that apply to a quantity in exclusion of others, the type of the quantity is different. There are further recomendations. On Tue, Dec 16, 2014 at 9:20 PM, Sean Woods s...@seanwoods.com wrote: I'm curious about the coding convention in fossil with respect to variable naming. It seems that the code follows something like the following convention: - integers have no prefix - strings have a z prefix e.g. zParam - pointers have a p prefix e.g. pSomething - function pointers have an x prefix e.g. xSaveAll What else is there? Is there any document that describes this convention? Perhaps also some rationale behind why this approach is used (hungarian notation being a somewhat controversial topic). Perhaps I'll even consolidate the info and contribute to the wiki... ___ 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] Hungarian Notation Used in Fossil
On Dec 16, 2014, at 7:37 PM, Richard Hipp d...@sqlite.org wrote:
But they are useful at times.
Yes. It’s not as useful as a type system that simply doesn’t let you do
questionable things,[*] but when you have to write in C or C++, it’s good to
buttress the type system with some notation.
I’ve used a similar system for decades:
a = array (some like v for vector instead)
b = Boolean
c = character (except when used as an 8-bit integer)
e = enum
f = floating-point number
g = global
h = handle (haven’t used this since my Win32 days)
k = constant
n = integer number
p = pointer
s = string (C++ only; C strings are pc or kpc)
_ = trailing underscore on C++ private member variables
They combine, of course:
const char* akpcStringTable[] = {
“lots”,
“of”,
“strings”
};
Some variant schemes I’ve come across separate the storage and access
specifiers (k, g) from the type specifiers with an underscore:
gk_apcStringTable would be a global array of const pointers to char. The
admixture doesn’t bother me, so I’ve never adopted that convention. It’s
common among Visual C++ users, where the trailing _ in my scheme becomes an m_
prefix, for “member”.
Notice that unlike MS style Hungarian, my integers are all ’n’, not
differentiated by storage size. Modern compilers are smart enough to avoid
this sort of problem, for the most part.
I did manage to confuse the C++ compiler a few months ago, though. I changed a
function returning bool (success/failure) to return 0/“error message” instead:
bool myFunction() {
if (happy) {
return true;
}
else {
return false;
}
}
became:
const char* myFunction() {
if (happy) {
return 0; // there’s only one kind of happy
}
else {
return “the frobnitzim have kerflamulated”; // but many kinds of
sad
}
}
My actual function was fairly complex, and I accidentally left one of the
“return false” calls unchanged. C++ allows false to convert to 0 which
converts to const char* which turned a failure condition into success! The
compiler didn’t even blink, even with -Wall. Perfectly sane according to GCC.
Grrr.
[*] e.g. ML family languages like OCaml and F#
___
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] Remove flat-view from menu? Was: File age in the tree view
Hi Richard, On 16 December 2014 at 17:05, Richard Hipp d...@sqlite.org wrote: Given the much improved tree-view functionality https://www.fossil-scm.org/fossil/tree?ci=trunkmtime Is there really any reason to keep the legacy Flat-View on the menu bar? https://www.fossil-scm.org/fossil/tree?ci=trunktype=flat I think the flat-view functionality should be preserved. (Who knows how many links to the flat-view exist on various wiki pages, tickets, and check-in comments.) But I don't see a reason to have it using up valuable menu-bar space. Nice job on taking it out. I like it and all the changes you've committed today. I especially like that there's the shading as you mouseover in the code section. Without this shading, it may make it harder for the eyeballs to travel over to the right modify date. When reviewing the flat view: https://www.fossil-scm.org/index.html/dir I'm wondering what order things are sorted/displayed in. Is it alphabetical, last modified, etc? I understand the CAPITAL letter file names no sorting correctly because that's unix but make is before (if you're reading left-to-right) auto.def and even ci_cvs.txt I also understand the dot files preceding everything else as well. The shading also means you didn't need to modify the alignment. If you're looking for other suggestions, then I suggest the rss link somewhere at https://www.fossil-scm.org/fossil/timeline I don't necessarily think it needs to have its own menu button but some place on the page so projects can be tracked easy, even in the footer would be good. It's already great there is an rss feed with fossil because I don't know how people using other SCM track changes, maybe they just update and see if there's changes. If the timeline isn't the ideal place, there's always the code section. Comments? -- D. Richard Hipp d...@sqlite.org Best, jungle -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Hungarian Notation Used in Fossil
This is excellent.
On Dec 16, 2014 9:31 PM, Warren Young w...@etr-usa.com wrote:
On Dec 16, 2014, at 7:37 PM, Richard Hipp d...@sqlite.org wrote:
But they are useful at times.
Yes. It's not as useful as a type system that simply doesn't let you do
questionable things,[*] but when you have to write in C or C++, it's good
to buttress the type system with some notation.
I've used a similar system for decades:
a = array (some like v for vector instead)
b = Boolean
c = character (except when used as an 8-bit integer)
e = enum
f = floating-point number
g = global
h = handle (haven't used this since my Win32 days)
k = constant
n = integer number
p = pointer
s = string (C++ only; C strings are pc or kpc)
_ = trailing underscore on C++ private member variables
They combine, of course:
const char* akpcStringTable[] = {
lots,
of,
strings
};
Some variant schemes I've come across separate the storage and access
specifiers (k, g) from the type specifiers with an underscore:
gk_apcStringTable would be a global array of const pointers to char. The
admixture doesn't bother me, so I've never adopted that convention. It's
common among Visual C++ users, where the trailing _ in my scheme becomes an
m_ prefix, for member.
Notice that unlike MS style Hungarian, my integers are all 'n', not
differentiated by storage size. Modern compilers are smart enough to avoid
this sort of problem, for the most part.
I did manage to confuse the C++ compiler a few months ago, though. I
changed a function returning bool (success/failure) to return 0/error
message instead:
bool myFunction() {
if (happy) {
return true;
}
else {
return false;
}
}
became:
const char* myFunction() {
if (happy) {
return 0; // there's only one kind of happy
}
else {
return the frobnitzim have kerflamulated; // but many kinds
of sad
}
}
My actual function was fairly complex, and I accidentally left one of the
return false calls unchanged. C++ allows false to convert to 0 which
converts to const char* which turned a failure condition into success! The
compiler didn't even blink, even with -Wall. Perfectly sane according to
GCC. Grrr.
[*] e.g. ML family languages like OCaml and F#
___
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] Edit code in fossil website
Hello All, Just to make sure I'm not missing something rather obvious, it's not yet possible to edit code / source within fossil, correct? I can see that it's possible to make changes to attributes of a specific check-in like the comments, color, and branching. This is from September 2011 so that's why I'm following up here: http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg06067.html Best, jb -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Hungarian Notation Used in Fossil
On Tue, Dec 16, 2014 at 10:29 PM, Warren Young w...@etr-usa.com wrote: On Dec 16, 2014, at 7:37 PM, Richard Hipp d...@sqlite.org wrote: But they are useful at times. Yes. It’s not as useful as a type system that simply doesn’t let you do questionable things,[*] but when you have to write in C or C++, it’s good to buttress the type system with some notation. I’ve used a similar system for decades: a = array (some like v for vector instead) b = Boolean c = character (except when used as an 8-bit integer) e = enum f = floating-point number g = global h = handle (haven’t used this since my Win32 days) k = constant n = integer number p = pointer s = string (C++ only; C strings are pc or kpc) _ = trailing underscore on C++ private member variables The thing I dislike about the strict Microsoft way is the embedding of actual type data into the variable name, so that if you decide to change a type later, you have to change all the names. (I realize the above quote is not the strict Microsoft way, just commenting). I like the idea of a loose Hungarian notation which helps you remember the general purpose of a variable (handle, string, number, pointer). I loathe ... uh ... do not care for ... the embedding of scope or constness. Which is not to say I never do it (when in Rome) but I still don't care for it. If source code is meant to be read by humans (as well as processed by compilers) then I want as little crypticness (is that a word) while reading as possible. The nature of programming prevents that from being achieved anywhere near 100% of the time, of course, but I prefer not to sound like I'm coughing up a furball if I'm discussing source out loud. :) My actual function was fairly complex, and I accidentally left one of the “return false” calls unchanged. C++ allows false to convert to 0 which converts to const char* which turned a failure condition into success! The compiler didn’t even blink, even with -Wall. Perfectly sane according to GCC. Grrr. Well, it's just a widening conversion of 0 from 1 bit to 32 or 64 bits. Of course it's sane! :) -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
