Re: [fossil-users] Merge SSH changes?
Thus said Richard Hipp on Mon, 05 Aug 2013 19:42:12 -0400: That's the way it used to work. I think Andy's changes fix it so that it doesn't work that way any more. I'm disappointed too, and would like to find a solution that works both ways. Ok, I've reimplemented the original test-http behavior as the default while retaining the ability to have the same flexibility in using Fossil capabilities with SSH URLs: http://www.fossil-scm.org/index.html/timeline?r=ssh-test-http When you get a chance, if this works out better. Basically, the default is to spawn a remote ``fossil test-http'' command when cloning (or even in an existing open fossil). But if the remote side requires http and not test-http (e.g. SSH keys are enforcing fossil http, then the client can request that as well: fossil clone --ssh-use-http ssh://amb@remote//tmp/new.fossil clone.fossil Which of course will require that the user enter the Fossil password. Thanks, Andy -- TAI64 timestamp: 40005204a36f ___ 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] simple Fossil For New Users intro guide
On Thu, Aug 08, 2013 at 10:48:36PM +0200, j. van den hoff wrote: 1. the Unlike most popular DVCSes... is a bit misleading. all of them have a database for each checkout, of course, but not in a single file. backing them up is not really that much more complicated. I would try to emphasize a bit more that the difference is indeed that fossil uses a monolithic database, i.e. a single file instead of a directory tree and that has indeed some advantages if you only use `cp' since you don't run into permission issues. I was trying to point out the distinction between the checkout and the repository file -- not to say that Git (for instance) doesn't have any database of version control. I tried to clarify the text, though, without overcomplicating things, given the very simple approach I'm trying to maintain. 2. I'm not comfortable with categorically recommending to new users to separate the database from the checkout. I know that many on this list think this to be a good thing but in general (as opposed to for special use cases) I don't think there is any advantage. keeping the database within the checkout (just as the others (git, hg, bzr, ...) do, has advantages, too (e.g. ability to move the whole thing around without closing/reopening the repo) and also allows to identify a checkout as being (or having been) under fossil control even when the repo is closed. so, I would mention both possibilities as being equally viable and it being mostly a matter of taste which to choose. (e.g., my preference is to put all the databases with a default name into the checkout dir (I use `.fslrepo') and put the server-side clones in a common location/directory. that works very well for me and would indeed not recommend to locally separate the databases from their checkouts). I don't want to turn the thing into a book-length exploration of all the options. It's meant to get people started quickly, and little else. I did rearrange things slightly in that paragraph to make it clearer that I did not intend a categorical imperative (apologies to Kant for abusing the term), but I did not add any digressions about the relative merits and flaws of differing approaches, which is better saved for other resources than mine. Hopefully this addresses your concerns. I appreciate the feedback. -- 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] simple Fossil For New Users intro guide
On 8 August 2013 22:25, Chad Perrin c...@apotheon.net wrote: This Fossil For New Users intro to doing the basics in Fossil was a few minutes' work, in part as a reminder for myself. I thought it might be useful for others as well, though, so I finally decided to put it online. http://blogstrapping.com/?page=2013.220.13.42.53 Let me know what you think. If there are any problems I'll try to fix them. -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] The bad thing about fossil is...
... that it's easy to get too used to it... [stephan@gf-dev:/kunden/trunk/DomainFactory/webseiten]$ f diff common/include/gf-common.inc.php current directory is not within an open checkout Aaarrggg - this is subversion! -- - 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] fossil misses a changed file (bug?)
On Fri, Aug 9, 2013 at 10:10 AM, j. van den hoff veedeeh...@googlemail.comwrote: On Fri, 09 Aug 2013 15:42:37 +0200, Richard Hipp d...@sqlite.org wrote: On Fri, Aug 9, 2013 at 9:33 AM, j. van den hoff veedeeh...@googlemail.com**wrote: I guess the problem might be related to `fossil' checking `mtime' with a too low time resolution. is this possible? it is of course irrelevant for interactive use but not so for scripts like this one. The default behavior is for Fossil to check both stat.st_mtime and so the time resolution here is 1 second, right? could that not be increased (say to 1 ms or so)? No, at least not in a cross-platform way. Many filesystems do not store timestamps with a resolution higher than one second. (Bummer, I know, but 40 years ago when mtime was first invented, a one-second timestamp was high resolution for the hardware available!) -- 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] incomplete documentation?
On Fri, Aug 9, 2013 at 1:36 PM, j. van den hoff veedeeh...@googlemail.comwrote: fossil --user joedoe ci filename fossil ci --user joedoe filename the second version looks normal in that `ci' apparently takes a `--user' option plus argument. the first one is the problem for the `fsl' wrapper since it of course cannot (and should not need to) mimic the complete command line parsing of `fossil' in order to get it correctly interpreted. A side-note on WHY that happens, for those who are interested... when find_option() is used to fetch a flag, the caller has to tell it the name of the flag and whether or not that flag expects a value. The the above case the name would be user and it does expect a value. So fossil starts looking through g.argv (an array of strings) to find the option. If it does, it _removes_ it from g.argv (and decrements g.argc: the count of items in g.argv). If the argument expects a value, it also removes the _next_ entry from g.argv and decrements g.argc. So after calling that, fossil effectively has fewer arguments than it had before, which means that the command can then simply look at g.argc to figure out if the user passed in the right number of arguments (for many cases, anyway, though some require more advanced logic). Anyway... i found those details highly interesting when i started work on the JSON API. At first the update-g.argv behaviour annoyed me (on a philosophical level), but now that i understand why it works that way, i'm good with it. bottom line: I really would be grateful if someone could clarify whether fossil COMMAND ?args and files? is actually the only valid syntax for command line usage (ignoring the `--args FILENAME' way of feeding `fossil' commands from a file) and that things like fossil --user joedoe ci filename are not guaranteed to work/should be avoided? The current code can't make such a guaranty. It can guaranty that the above two variants are functionally equivalent, but ONLY if the specific command handler does its argument/flag checks in such a way that makes them equivalent. i.e. the commands which do all flag-checking up front, before examining other arguments will treat the above as equivalent because the flag-checking filters out g.argv for their later processing. In case you don't know about it, there's another seldom-used feature which potentially adds even more confusion/combinations to your examples: the --args FILENAME option, which basically replaces the (--args FILENAME) args with the contents of the given filename: http://fossil-scm.org/index.html/artifact/952d72d35e5ab9ea4815d68e7820d9deae701433?ln=357-366 -- - 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] simple Fossil For New Users intro guide
On Fri, Aug 09, 2013 at 12:15:57PM +0200, Michai Ramakers wrote: On 8 August 2013 22:25, Chad Perrin c...@apotheon.net wrote: This Fossil For New Users intro to doing the basics in Fossil was a few minutes' work, in part as a reminder for myself. I thought it might be useful for others as well, though, so I finally decided to put it online. http://blogstrapping.com/?page=2013.220.13.42.53 Not much constructive criticism from me, but instead let me say this looks good and useful. Minimal workflow and pointers where to go from here. I like the verbatim command-line dialog as well. Thanks. If you want, you might - as an advertisement tool so to say - point the user towards the Fossil main site (why isn't there a link already..?) and mention early in your text that this is a self-hosting repository. (Being able to see how it works hands-on was a big reason for me giving it a try.) I meant to add a link to the main site at the beginning, and it just completely slipped my mind. Thanks for reminding me. In section 'Managing Project Files', you have 'fossil status' twice in a row, btw. . . . and that has been fixed as well. It was an artifact of editing, I think. Unlike Fossil, I'm afraid I am not transactional. -- 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] simple Fossil For New Users intro guide
On Fri, Aug 9, 2013 at 2:01 PM, Richard Hipp d...@sqlite.org wrote: Fossil and Monotone uses a relational database whereas Git uses an ad-hoc pile-of-files database. snip Reminder to self or other dev: that whole answer belongs verbatim in one of the wiki/doc pages, IMO, if it's not there already. -- - 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] incomplete documentation?
El 09/08/2013 14:18, Richard Hipp d...@sqlite.org escribió: On Fri, Aug 9, 2013 at 7:40 AM, Isaac Jurado dipto...@gmail.com wrote: As I understand it, in Fossil, the history is mostly driven by the date and time of the events, whereas in Git and Hg ancestry relationship comes first. I gues this is one of the reasons of why there typical log command is called timeline in Fossil; and also why hiding the possibility of altering the commit time, because it would lead to a confusing timeline graph. When I converted an Hg repo that had its history reordered (with hg histedit), the resulting Fossil timeline had an arrow pointing downwards which made it look a bit weird. The timeline display in Fossil is date driven. But the underlying repository uses ancestry relationships, just like Git and Mercurial. Sure, I didn't mean otherwise. What I was trying to explain is that when using Git or Mercurial one is under the impression that commit dates are just informative. However, Fossil's timeline pays more attention to dates. Of course, all systems properly record ancestry relationships. When you have a parent that is younger than its child, we call that a time-warp and it results in a funky backwards arrow on the timeline display. See http://www.sqlite.org/src/timeline?c=3f30f00a384dnd for an example. Timewarps can be caused, for example, when commits occur on a system were the system clock is set to the wrong time. When doing a sync, Fossil compares timestamps on the local and remote machines and issues a warning if they are misaligned. The whole point of that warning is to try to prevent timewarps. You can get a list of all timewarps in a project by visiting the /test_timewarps page in the web interface. There were several timewarps in the SQLite history (as seen at http://www.sqlite.org/src/test_timewarps) but most of them have been fixed by adding tags to check-ins that correct their check-in time. The http://www.sqlite.org/src/info/cbfe6e9df3check-in, for example, had an original check-in time of 2009-08-20 09:11:06 but this was adjusted to 2009-08-20 16:11:06 for display purposes using a tag, specifically the http://www.sqlite.org/src/info/14cc3387df tag. You could, in theory, generate timewarps in Git too, since each check-in has a timestamp, iirc. Does anybody know what would happen on the GitHub timeline graph for a Git repository that contains a timewarp? I can't speak for git, but in Mercurial when examinig the history graph the dates are secondary. Therefore, time warps are not highligthted and it's up to the user to check. Thanks for the other information. ___ 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] simple Fossil For New Users intro guide
The more newbie help the better... I - for one - certainly appreciate it. On the fossil files in or out of the project directory, I suspect most of the cases Stephen and others have had with mangling/deleting fossil db files could be obviated (on Linux and Mac OS X) by calling the fossil file something like .fossil so wild cards don't match. ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] `fossil mv' question
if I do `fossil mv a b'; mv a b; and then edit the renamed file `b' and
check it in, I can
do a
`fossil diff -r {before_rename} --to{after_rename}'
between revisions before and after the rename and get the correct diff
listing of `a' vs. `b' as it should be.
adding the file name of the currently existing file `b' i.e. using
`fossil diff -r {before_rename} --to{after_rename}' b
tells me (correctly) that `b' is not present in {before_rename}. but since
the rename info is there it would be nice to get the same diff as without
specifying the file (`hg', e.g., behaves this way). when there is only a
single file differing between the revisions is not that important but if
there are multiple affected files it makes a difference whether the second
variant works or not.
question: why does it fail when specifying the name but works when I omit
it?
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
[fossil-users] `fossil mv' question (II)
sorry for the noise in the previous mail. I erroneously stated that I get the full diff for the renamed file when not specifying the file name which is *not* correct. so please forget that. so it seems that diffs across renames do not work currently at all. is that correct? so fossil only logs the rename as DELETED plus and ADDED action w/o keeping track of the rename any more so a diff can only be done manually by extracting both revisions (pre/post rename) from the repo? j. ___ 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] simple Fossil For New Users intro guide
On Fri, Aug 9, 2013 at 6:17 PM, David Mason dma...@ryerson.ca wrote: On the fossil files in or out of the project directory, I suspect most of the cases Stephen and others have had with mangling/deleting fossil db files could be obviated (on Linux and Mac OS X) by calling the fossil file something like .fossil so wild cards don't match. Almost: find . -type f | xargs ... i've done that, too, i'm ashamed to admit :/. Obviously, it's stupid user error, not Fossil's problem, but my chance of such stupid user errors drops to near 0 if simply keep the fsl file somewhere else. i would never ever want my CVSROOT/SVNROOT to be in the current checkout dir, nor my main git repo to be my working checkout, and can't imagine doing the same (ever again ;) with fossil. -- - 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] simple Fossil For New Users intro guide
On Fri, Aug 09, 2013 at 12:17:00PM -0400, David Mason wrote: The more newbie help the better... I - for one - certainly appreciate it. I wrote a set of notes years ago covering the issues described in this guide, as reminders for myself. I kept meaning to flesh it out a bit and post it online, but never got around to it until yesterday -- and then only because an acquaintance needed the help this could provide, so I updated the notes (it had gotten a bit out of date with the current state of affairs in Fossil SCM land), filled in a bunch of explanatory text, and finally posted it. If it helped me when I wasn't yet used to Fossil, and helped this acquaintance of mine, I figured it might help others as well. -- 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] `fossil mv' question (II)
On Fri, Aug 9, 2013 at 12:28 PM, j. van den hoff veedeeh...@googlemail.comwrote: so fossil only logs the rename as DELETED plus and ADDED action w/o keeping track of the rename any more so a diff can only be done manually by extracting both revisions (pre/post rename) from the repo? Fossil does keeps track of renames. But the current diff logic does not make use of that information. Part of the problem arises from syntax. If you type: fossil diff --from abc --to cde xyz.txt Are you meaning the diff the file xyz.txt in version abc against whatever that file is called in version cde. Or do you mean to diff the xyz.txt in cde against the equivalent file in abc? As I sit here and ponder the problem, I think I prefer the current behavior anyhow. I think the command above should mean to compute the diff between file called xyz.txt in the two specified versions, regardless of their relative ancestry. If you want to diff file xyz.txt in one version against file pqr.txt in another version, you should say so. (That is not something that the diff command currently supports directly, but it could be added, I suppose, and I'd be more inclined to add that than to make the diff command magically track file renames through time.) The other part of the problem is that I do most of the implementation for things like this and I rarely ever rename files in a project, so diffing between two versions of a file whose name has changed is not something that comes up for me very often, and hence is not a priority. You are more than welcomed to submit patches if it is a priority for you, though. -- 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] `fossil mv' question (II)
On Fri, 09 Aug 2013 18:42:59 +0200, Richard Hipp d...@sqlite.org wrote: On Fri, Aug 9, 2013 at 12:28 PM, j. van den hoff veedeeh...@googlemail.comwrote: so fossil only logs the rename as DELETED plus and ADDED action w/o keeping track of the rename any more so a diff can only be done manually by extracting both revisions (pre/post rename) from the repo? Fossil does keeps track of renames. But the current diff logic does not make use of that information. Part of the problem arises from syntax. If you type: fossil diff --from abc --to cde xyz.txt Are you meaning the diff the file xyz.txt in version abc against whatever that file is called in version cde. Or do you mean to diff the xyz.txt in cde against the equivalent file in abc? one could decide once and for all which variant is intended. `hg', e.g., uses your variant 2 (file refers to the `--to' revision, which intuitively is somewhat better (especially if `--to' is omitted in which case it ensures that `file' is just the working copy which the user wants to diff against a former version before the rename. so that is a non-issue as far as I can see. As I sit here and ponder the problem, I think I prefer the current behavior anyhow. I think the command above should mean to compute the diff between file called xyz.txt in the two specified versions, regardless of their relative ancestry. If you want to diff file xyz.txt in one version against file pqr.txt in another version, you should say so. (That is not something that the diff command currently supports directly, but it could be added, I suppose, and I'd be more inclined to add that than to make the diff command magically track file renames through time.) you are the one who decides this. but I would argue that a diff between differently named files (not connected by a rename) is not that useful a feature for the revision control system. on the other hand, a diff across renames I feel is _quite_ useful since I'm sure file renaming (including moving files to different or newly created dirs: I'm not sure whether such a `mv' is any different from renaming the file itself?) is happening quiet often for one reason or other. I try to avoid them but of course they happen and obviously the user is interested in using the system across the rename boundaries. The other part of the problem is that I do most of the implementation for things like this and I rarely ever rename files in a project, so diffing between two versions of a file whose name has changed is not something that comes up for me very often, and hence is not a priority. You are more again, you decide that (whether or not important to you). I suspect it's not the majority view, though. and PR wise the competitors usually make quite a big point of diff tracking capabilities across renames. than welcomed to submit patches if it is a priority for you, though. would be willing to do that if I were more fluent in C (let alone anything sql) than I am these days. so I'm afraid that's not too realistic, unfortunately. and I have no idea how much work (meaning how complicated) it would be: you say it's only the diff logic? does that mean that mostly one only would have to resolve the syntax issue (my vote would go to mimicking `hg' here, since it is sure the right behavior, especially if only `-r' is specified) and that than the required information (and artifacts to pick) would be easy to feed to the diff? 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] `fossil mv' question (II)
On Fri, Aug 9, 2013 at 8:24 PM, j. van den hoff veedeeh...@googlemail.comwrote: to different or newly created dirs: I'm not sure whether such a `mv' is any different from renaming the file itself?) A mv is a rename, and Fossil remembers it all. In Unix (not sure about Windows), a 'mv' is also just a rename unless the target is on another filesystem, in which case it is a copy-then-delete. If you do a bunch of renaming/moving, but do no edits, you might be surprised how little data fossil has to save. i had a commit a day or two ago with about 15 renames and the push reported only 2000 bytes sent. The other part of the problem is that I do most of the implementation for things like this and I rarely ever rename files in a project, so diffing between two versions of a file whose name has changed is not something that comes up for me very often, and hence is not a priority. You are more again, you decide that (whether or not important to you). I suspect it's not the majority view, though. and PR wise the competitors usually make quite a big point of diff tracking capabilities across renames. FWIW, i second Richard on this. It's so rarely needed (for us, at least) that it's not worth the effort to implement. git is scary smart about the movement of content between files (at the sub-file level, even), but for projects of the scale/scope Fossil was designed for, that seems like overkill. i honestly remember a single time i've thought, man, if i could only diff those two renamed files. And if i did, i'd just check them both out and run them through my local diff/compare tool. would be willing to do that if I were more fluent in C (let alone anything sql) than I am these days. You don't need much SQL to work on Fossil, and there's much to learn about it from fossil. Copy/paste gets you a long ways, too. i'm certainly no SQL guru. But without C... we'll just have to accept your patches in the form of email text descriptions ;). -- - 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] `fossil mv' question (II)
On Fri, 09 Aug 2013 20:33:59 +0200, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 9, 2013 at 8:24 PM, j. van den hoff veedeeh...@googlemail.comwrote: to different or newly created dirs: I'm not sure whether such a `mv' is any different from renaming the file itself?) A mv is a rename, and Fossil remembers it all. In Unix (not sure about Windows), a 'mv' is also just a rename unless the target is on another filesystem, in which case it is a copy-then-delete. If you do a bunch of renaming/moving, but do no edits, you might be surprised how little data fossil has to save. i had a commit a day or two ago with about 15 renames and the push reported only 2000 bytes sent. yes, sure (I'm only talking about unix, anyway...) I just was not sure whether this makes any difference as far as fossil is concerned. I would suspect that this sort of renaming (moving files to different directories) is happening quite often in modestly large projects. The other part of the problem is that I do most of the implementation for things like this and I rarely ever rename files in a project, so diffing between two versions of a file whose name has changed is not something that comes up for me very often, and hence is not a priority. You are more again, you decide that (whether or not important to you). I suspect it's not the majority view, though. and PR wise the competitors usually make quite a big point of diff tracking capabilities across renames. FWIW, i second Richard on this. It's so rarely needed (for us, at least) that it's not worth the effort to implement. git is scary smart about the movement of content between files (at the sub-file level, even), but for projects of the scale/scope Fossil was designed for, that seems like overkill. i honestly remember a single time i've thought, man, if i could only diff those two renamed files. And if i did, i'd just check them both out and run them through my local diff/compare tool. sure, but it is not quite what you would have liked to have in that moment. and that man, if I could moment might happen quite often, wenn summed over the user community. would be willing to do that if I were more fluent in C (let alone anything sql) than I am these days. You don't need much SQL to work on Fossil, and there's much to learn about it from fossil. Copy/paste gets you a long ways, too. i'm certainly no SQL guru. But without C... we'll just have to accept your patches in the form of course I do know C soso but haven't used it seriously in many years. so I'm quite sure it would not be the best idea to dive into the fossil code right now and to mess it up. ;-) of email text descriptions ;). that's what I did I thought? I mean the question really is: is this a big change to the code or is the bottleneck to _understand_ what to do (because in the latter case one of the developers might need an hour where someone else needs a month or whatever). and to be clear: I did not try to demand such a change. I just think it would make fossil a better program if it had this functionality. 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] `fossil mv' question (II)
On Fri, Aug 9, 2013 at 8:49 PM, j. van den hoff veedeeh...@googlemail.comwrote: sure, but it is not quite what you would have liked to have in that moment. and that man, if I could moment might happen quite often, wenn summed over the user community. Agreed, but in that case it would probably have taken me longer to (A) figure out if fossil could do that and (B) search through the help than it would to do fossil cat on both files and diff them myself (i live on the command line already). of course I do know C soso but haven't used it seriously in many years. so I'm quite sure it would not be the best idea to dive into the fossil code right now and to mess it up. ;-) i had given up C in 1995 in favour of higher-level languages (scripting, which was new to me at the time), and Fossil was the reason i returned to it in late 2007 (though i had been doing a lot of C++ since 2000, so getting back into it wasn't too difficult). Since i got into hacking fossil, probably 80% of my open source code (not counting fossil) has been in C. Try it - you might like it :). of email text descriptions ;). that's what I did I thought? Yes, of course :). I mean the question really is: is this a big change to the code or is the bottleneck to _understand_ what to do (because in the latter case one of the developers might need an hour where someone else needs a month or whatever). i can't comment on the complexity. Only a small handful of the devs (not me!) have ever done any significant work on the low-level delta/manifest/lineage/diff bits. The vast majority of the code at that level has only ever been hacked upon by Richard. While porting in code to libfossil, i'm fairly certain i'm the only human, other than Richard, who has seen some of these bits in years ;). and to be clear: I did not try to demand such a change. I just think it would make fossil a better program if it had this functionality. No, it didn't come across as a demand - you've backed up all of your talk with decent arguments. It's just that the feature doesn't much interest anyone who's capable of/willing to implement 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] Status of the hidden tag
Hi all, My apologies for being noisy with this. I think it was unclear what I was specifically asking. I don't shun things, but there are times where I'd like to clean up the main timeline view for public (aka customer) consumption. I can see that adding a 'hidden' tag is suggested as a better alternative to shunning. My questions are: - Can I add the hidden tag to a check in? If not, what can I add it to? - Should I add it from the web interface or do I need to add it from the cli with the --raw option? - Does adding it do anything at this time? - If not, is this still a planned feature or should I forget I read about it? And maybe should the wording on /shun be updated? Thanks in advance, Themba On Thu, Jul 25, 2013 at 11:03 AM, Themba Fletcher themba.fletc...@gmail.com wrote: From fossil's /shun page: Do not shun artifacts merely to remove them from sight - set the hidden tag on such artifacts instead. The only other reference I could find while searching this list was a note from drh (circa 2009 or so?) noting that it had not been implemented yet. Is this still the case? I just tried, via the web interface, adding a hidden tag to a checkin on one of my mistake branches and the timeline still showed the item. Perhaps there's a setting I've missed -- or perhaps something else? $ fossil version This is fossil version 1.26 [674a24a360] 2013-07-20 16:43:45 UTC Best Regards, 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] Status of the hidden tag
On Fri, Aug 9, 2013 at 10:32 PM, Themba Fletcher themba.fletc...@gmail.comwrote: I don't shun things, but there are times where I'd like to clean up the main timeline view for public (aka customer) consumption. I can see that adding a 'hidden' tag is suggested as a better alternative to shunning. My questions are: i can't answer your questions (i have never shunned) but can offer a (sub-optimal) alternative: disable the timeline view for them and maintain a hand-written changelog in the wiki or embedded docs for them. -- - 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] Status of the hidden tag
On Fri, Aug 9, 2013 at 4:32 PM, Themba Fletcher themba.fletc...@gmail.comwrote: Hi all, My apologies for being noisy with this. I think it was unclear what I was specifically asking. I don't shun things, but there are times where I'd like to clean up the main timeline view for public (aka customer) consumption. I can see that adding a 'hidden' tag is suggested as a better alternative to shunning. My questions are: - Can I add the hidden tag to a check in? If not, what can I add it to? - Should I add it from the web interface or do I need to add it from the cli with the --raw option? - Does adding it do anything at this time? - If not, is this still a planned feature or should I forget I read about it? And maybe should the wording on /shun be updated? Hidden is one of those planned features that I never got around to implementing. It shouldn't be that hard to add. Probably just a small adjustment to WHERE clause of the main query that does the timeline. But as far as I know, the hidden flag is currently just a no-op. Thanks in advance, Themba On Thu, Jul 25, 2013 at 11:03 AM, Themba Fletcher themba.fletc...@gmail.com wrote: From fossil's /shun page: Do not shun artifacts merely to remove them from sight - set the hidden tag on such artifacts instead. The only other reference I could find while searching this list was a note from drh (circa 2009 or so?) noting that it had not been implemented yet. Is this still the case? I just tried, via the web interface, adding a hidden tag to a checkin on one of my mistake branches and the timeline still showed the item. Perhaps there's a setting I've missed -- or perhaps something else? $ fossil version This is fossil version 1.26 [674a24a360] 2013-07-20 16:43:45 UTC Best Regards, Themba ___ 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] Status of the hidden tag
On Fri, Aug 9, 2013 at 1:43 PM, Richard Hipp d...@sqlite.org wrote: On Fri, Aug 9, 2013 at 4:32 PM, Themba Fletcher themba.fletc...@gmail.com wrote: Hi all, My apologies for being noisy with this. I think it was unclear what I was specifically asking. I don't shun things, but there are times where I'd like to clean up the main timeline view for public (aka customer) consumption. I can see that adding a 'hidden' tag is suggested as a better alternative to shunning. My questions are: - Can I add the hidden tag to a check in? If not, what can I add it to? - Should I add it from the web interface or do I need to add it from the cli with the --raw option? - Does adding it do anything at this time? - If not, is this still a planned feature or should I forget I read about it? And maybe should the wording on /shun be updated? Hidden is one of those planned features that I never got around to implementing. It shouldn't be that hard to add. Probably just a small adjustment to WHERE clause of the main query that does the timeline. That looks like an interesting place to start hacking on fossil, so I'll take that as a challenge :) Thanks for the answer, T ___ 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] Status of the hidden tag
On Fri, Aug 9, 2013 at 1:39 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 9, 2013 at 10:32 PM, Themba Fletcher themba.fletc...@gmail.com wrote: I don't shun things, but there are times where I'd like to clean up the main timeline view for public (aka customer) consumption. I can see that adding a 'hidden' tag is suggested as a better alternative to shunning. My questions are: i can't answer your questions (i have never shunned) but can offer a (sub-optimal) alternative: disable the timeline view for them and maintain a hand-written changelog in the wiki or embedded docs for them. Yep, that would work. I could also, since I was thinking specifically of using the RSS feed, maybe cobble something together out of the JSON api -- basically just a new version of timeline.rss with any hidden checkins removed. Food for thought, 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] Status of the hidden tag
On Fri, Aug 9, 2013 at 11:31 PM, Themba Fletcher themba.fletc...@gmail.comwrote: Yep, that would work. I could also, since I was thinking specifically of using the RSS feed, maybe cobble something together out of the JSON api -- basically just a new version of timeline.rss with any hidden checkins removed. Food for thought, thanks. It might interest you to hack on libfossil, which will allow customized apps/mini-apps like that to be quickly thrown together. As a concrete example, here's a custom timeline implemented using the script bindings for libfossil: [stephan@host:~/cvs/fossil/f2/th1ish]$ ./th1ish timeline.th1ish -- -n=4 The 4 most recent timeline event(s) for /home/stephan/cvs/fossil/f2/.fslckout: ci @ 2013-08-09 23:20:24 [423842eb262c] by [stephan] in branch [trunk] doc updates w @ 2013-08-09 22:33:28 [7a2e57c50e8e] by [stephan] Changes to wiki page [home] ci @ 2013-08-09 22:29:49 [78bf9244bd16] by [stephan] in branch [trunk] Changed return semantics of fsl_list_reserve(), for consistency (old semantics were copy/pasted). Ran some code through reformatter. ci @ 2013-08-09 22:17:26 [f4e5795f9ec7] by [bch] in branch [trunk] buh-bye commented-out code. We've got version control here... The script looks like: http://fossil.wanderinghorse.net/repos/f2/index.cgi/artifact/b237bad93179931493968494feb043f6aa19e8d6 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
