Re: [fossil-users] some questions about fossil-as-document-repo
On Thu, 17 Jan 2013 18:53:43 +0100, C. Thomas Stover c...@thomasstover.com wrote: On Thu, 17 Jan 2013 07:55:09 -0600 Carson Chittom car...@wistly.net wrote: C. Thomas Stover c...@thomasstover.com writes: Well if hardcopy means scanned paper (no ocr) then it sounds like a very large binary file set. I'm showing my ignorance, but does OCR matter in this case? We already have OCR capabilities, and I had intended to scan in the documents using it--because, why not, if you can? I didn't think to mention it in my original post to the list because I didn't think it would change the average file size significantly. Well think about like this. In order to get a good enough detail for most purposes, these document scanners have somewhere around 600x600dpi resolution. At first you might think monochrome would work great (and it is still used sometimes with very high res modes), but in practice gray scale (or color) is really needed for handwriting, old paper, charts, and all sorts of applications. So the uncompressed bitmap for a single page can be quite big. So what about image/raster data compression? Well you either have loss-less (PNG) which works great for rendered vector graphics (diagrams, screen shots, etc), or loss-y (JPEG) which uses the characteristics of they way human vision processes colors to really work great for photographs. Neither one of these work that good for generic pieces of paper. What ends up happening is people just do an image resize to a smaller resolution, which (especially for handwriting) can be self defeating. On the other hand think how much space it takes for a page of UTF-8 text. Not much. So perfect OCR (which is a virtual impossibility) would take a 10+mb bitmap and convert it into a 2k text file. The solution today's technology uses is by using a container format like PDF where both images and text can be stored, the scanner software/firmware will OCR what it can and then mix that with little cropped images. This of course leads to the your mileage may very file sizes. just my 2c: there's also djvu http://djvu.org/ which provides astonishingly good compression for scanned documents, separation of layers, OCR etc. and there are converters from pdf to djvu around. otherwise I don't think that a SCM is really the suitable tool for your intended purpose (which I perceive as maintaining/backing up a list of versioned binary files): all SCMs that I know are not really good at handling big binary data sets (and delta-compression sure will not work that great...). so the repo will get real big in no time (and, for a DVCS, be copied to each and every user's account). but all the things the SCM offers (diffing, branching, merging) will _not_ work with binary data in a sensible way (I believe) and this also seems not to be what you need anyway. so the question is: why put it under revision control at all? the meta-information provided by the checkin-messages in the timeline alone would not be a sufficient reason in my view. I could imagine that a very basic solution (use the file system and maintain a logfile (or a (sqlite?) database (or fossil repo) of the metadata (file xyz.version_123 has this or that content and can be found here: and, possibly, as already suggested, an OCR dump) is more sensible. as said: just my 2c. -- 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] timeline bug?
On Wed, 16 Jan 2013 18:28:24 +0100, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jan 16, 2013 at 5:48 PM, j. van den hoff veedeeh...@googlemail.comwrote: is this a bug or a feature? I do hope the former since it's really bad behaviour when driving `fossil' with a script. It's an as designed bug. The argument handling is based on the argument count, and an empty argument is counted (the shell gives us an empty string in that case). We could arguably tweak the base args parsing (which happens at a much earlier stage) to ignore empty tokens, but i'm not sure that's a good idea. e.g. it would prohibit (commit -m '') and would cause very unwanted side-effects with (commit -m '' foo.bar). Alternately, we could improve the handling for this specific command, but be aware that this is only one of many commands which are likely affected by similar corner cases. The relevant code is here: http://fossil-scm.org/index.html/artifact/2560da3ea2ed20a85769cd44f1c83f672b2db2c0?ln=1587-1614 thanks for clarification. I understand that empty arguments can make sense in some cases (whether empty commits really do, we don't quite agree, obviously...) but I nevertheless don't understand what fossil timeline '' is actually meaning. the empty string is taken as what? the `when' (plus `baseline|date'?) argument? why is it showing timeline before *CURRENT* in this case? and apart from that, as I said, the current behaviour is prone to confuse other users, too, I'd say and it is really somewhat ugly regarding handling it gracefully from within a script (if a variable argument string is constructed and migh - in cases - turn out to be the empty string, cause with the given behaviour I would have to test for this and handle differently). so maybe this should still be decided on a per-command base (and an empty value to an option is also a different thing (or at least could be handled differently) then an empty string as argument, right?). 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] problem with selecting timeline entries for diffing in the GUI
my question regards the (very useful!) functionality of selecting (clicking) two timeline entries in the web GUI to the repo for diffing. this works alright for me with a certain (remote) repository. it does +not+ work for the local copy of that repo or any other local repo (under URL http://localhost:8080/timeline), i.e. the first click on a timeline square remains ineffective (no red highlight) as does the second (no diff appearing). what am I missing? -- 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 info' feature request (a.k.a. wish)
hi, I would find it useful if `fossil info' (or `stat', `timeline', or a new command) would provide a means/option to show the total number of revisions (by default or optional), more precisely, the number of file commits (as it is called in `fossil help timeline) in the repo. the information should be there in the database (or could be added?) and an additional line of output in `fossil info' would then do the trick. (sure one could also write a script analyszing `fossil timeline -ci ...' output to derive this information but this is not desirable for large repos in my view.) I would appreciate consideration of this proposal. greetings, j. ps: while I'm at it: adding the relative revision numbers to the output of `fossil timeline -ci' _and_ making them acceptable as keys instead of the SHA1 hashes in the relevant commands (notably `diff') would be very nice, too, but probably require more substantial changes. -- 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 info' feature request (a.k.a. wish)
On Thu, 10 Jan 2013 13:35:06 +0100, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Jan 10, 2013 at 12:56 PM, j. van den hoff
veedeeh...@googlemail.com
wrote:
I would find it useful if `fossil info' (or `stat', `timeline', or a new
command) would provide a means/option to show the total number of
revisions
(by default or optional), more precisely, the number of file commits
(as
it is called in `fossil help timeline) in the repo. the information
should
be there in the database (or could be added?) and an additional line of
output in `fossil info' would then do the trick. (sure one could also
write
a script analyszing `fossil timeline -ci ...' output to derive this
information but this is not desirable for large repos in my view.)
i'll sign up for adding that - i would be able to do this on Sunday. i
would add it to the status command because we have that info in the
/stat
page already (and in fossil json stat -full).
ps: while I'm at it: adding the relative revision numbers to the output
of
`fossil timeline -ci' _and_ making them acceptable as keys instead of
the
SHA1 hashes in the relevant commands (notably `diff') would be very
nice,
too, but probably require more substantial changes.
The DVCS model means that _relative_ (sequential) revision numbers are
rendered absolutely meaningless because multiple users can work offline
in
parallel (and their system clocks might not be properly synced, breaking
time-based ordering). The sequential numbering problem is, in effect,
impossible to solve in a DVCS.
I'm aware of this and that's why I wrote relative in the first place.
still, the numbers do make sense _locally_ as a very handy means of
denoting/selecting a revision. confusion _could_ arise if different people
talk about revision 11 without being aware that this is no good and they
need to use the sha1 hash (but practically, this should not be an issue).
by the way, the idea is not mine anyway but stolen from mercurial which
does just that, namely reporting the time line with identifiers formatted
as {rel_rev_number}:SHA1 and both (the rel. rev. and the hash) are
accepted in `diff' and friends.
works like a charm and saves lots of typing (locally chronological rev.
nums are much easier to memorize (and to type...) than sha1 hashes).
so I still think this would be useful.
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 info' feature request (a.k.a. wish)
On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com wrote: i'll sign up for adding that - i would be able to do this on Sunday. i would add it to the status command because we have that info in the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 thank you! -- 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 info' feature request (a.k.a. wish)
On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com wrote: i'll sign up for adding that - i would be able to do this on Sunday. i would add it to the status command because we have that info in the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 did not yet recompile and test, therefore short question: this is the total number of checkins (including wiki edits etc)? contrary to my last mail this would be actually the relevant info needed for creating the rel. checkin numbers I was talking about. 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] spurious CRLF generated by `finfo -p' (and other terminal output)
hi, I accidentally noted that all terminal (stdout) output of `fossil' seemingly uses CRLF (\r\n) as EOL even on unix-based machines (i.e. everything in the world except those view machines running something else ;-)). at least it does so under MacOSX. I would find it more reasonable if `fossil' would adjust its EOL convention to that of the underlying OS. especially `fossil finfo -p somefile.txt acopy.txt' is rather annoying since (assuming *CURRENT* is at the respective `leave') the checked out version of `somefile.txt' is then _not_ identical to `acopy.txt' (since the latter has the CRLF EOLs while `somefile.txt' has not). is this considered a bug?? if not so, could this behavior be changed nevertheless? 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] PLOS (II)
hoping that this does not generate so much turbelence as the mv/rm issue did: I've stumbled over this behavior: -- there is a user account on a remote repo created for me (with commit access) -- I do the clone a la `fossil clone http://myname@URL myrepo.fsl and I'm asked correctly for the password of user `myname'. -- I open my repo, edit stuff and commit/push -- commit/push turns out to use my $USER (local user name) and that's how it appears on the remote sites timeline well, I was heavily surprised which proofs that PLOS was violated. (least surprising always being that things don't work at all...). I would find it far more intuitive if _after_ a `clone' of the above sort (password query for `myname' and all) the corresponding local user would be created automagically and also be set to the default user so that I'm directly interacting correctly with the remote server. presently (and that's the parallel to the mv/rm discussion) I have to perform manual interaction (create user with password (take care to use the same as on the server here?) and make him the default user) which again 99.9% of the time should be what the user wants anyway (and might be really surprised to not have happened autmatically). right or wrong? 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] spurious CRLF generated by `finfo -p' (and other terminal output)
On Thu, 20 Dec 2012 19:03:07 +0100, Richard Hipp d...@sqlite.org wrote: On Thu, Dec 20, 2012 at 12:47 PM, j. van den hoff veedeeh...@googlemail.com wrote: hi, I accidentally noted that all terminal (stdout) output of `fossil' seemingly uses CRLF (\r\n) as EOL even on unix-based machines (i.e. everything in the world except those view machines running something else ;-)). at least it does so under MacOSX. I would find it more reasonable if `fossil' would adjust its EOL convention to that of the underlying OS. especially `fossil finfo -p somefile.txt acopy.txt' finfo does not use any EOL. It simply outputs what is in your file. It treats all files as binary. If you are seeing \r characters in the output above, that is because you checked \r characters into somefile.txt, I think. thanks for the quick answer. you are right, there are no \r, but the reason is different (still my fault!): I use a wrapper script for driving `fossil' and _that_ script somehow injects the \r. I have to check this. really sorry for the additional noise j. is rather annoying since (assuming *CURRENT* is at the respective `leave') the checked out version of `somefile.txt' is then _not_ identical to `acopy.txt' (since the latter has the CRLF EOLs while `somefile.txt' has not). is this considered a bug?? if not so, could this behavior be changed nevertheless? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 14:09:46 +0100, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 12/13/12 05:07, Carson Chittom wrote: Nolan Darilek no...@thewordnerd.info writes: If we're talking about adding git to the name because of this whole rm thing, we might as well consider mercurial as a candidate too. Mercurial behaves sensibly and removes the file automatically on rm. Naysayers aren't trying to make Fossil Git, we're just trying to make it do what most other VCSs do in these areas. Speaking as someone who has absolutely no investment--emotional, professional, or otherwise--in any VCS other than fossil (and also as a non-programmer), is what most other VCSs do so important? It's not; there's an important level of indirection that you're overlooking. Other VCS's do it automatically because it's the most intuitive way to do it. I.e. we want to do like other sane VCS's because *they do it the sane way* (not because they do it in higher numbers). If all other VCS would require two separate operations, I would still want fossil do it automatically in one operation. I know it's being lazy, but sometimes it's simply easier to make the argument everyone else is doing it, and let the readers themselves think about _why_ others do it that way. Seems like--while there's certainly potential room for tweaking--there's a fundamental disconnect, philosophically, between 1) what is in the filesystem 2) what is kept in version control and while the twain shall meet occasionally (to say the least), they are not *necessarily* the same. Fossil, after all, is a version control system, not a filesystem management system. It seems wholly natural to me that fossil rm x should mean remove the file x from version control, since version control is fossil's raison d'etre. To my way of thinking, VCSs which also really delete the file when removing it from version control are violating their fundamental paradigm. Proper data separation philosophies isn't the reason I use VCS's. There are aspects of proper design which I find to be important, but in the face of being practical, guaranteeing history integrity, and a few other properties I could care less about conceptual proper separation of filesystem/VCS data abstraction layers. More importantly: I use a fossil in a filesystem (open, checkout, rm, mv, update, etc), and hence I expect it to do filesystem operations for me. Which is does, sans rm and mv. I don't buy the it's separate layers argument; a lot of working directory filesystem operations are already an integral part of fossil -- why exclude rm and mv? But sticking to the practical side of things: If people are anyways in 99.99% of the cases going to follow a fossil rm by an rm, and a fossil mv by an mv, then I think we should start thinking about whether it's really necessary to require them to do so when we're in the perfect situation to do it for them. Say fossil changes the behavior and performs the requested filesystem operations immediately, and a few people are really upset about it. I could write a wrapper script for those uses which does essentially the following: cp $file $file.tmp fossil rm $file mv $file.tmp $file That way, people can still do it in two separate steps if they want to. Now, consider how many times this will actually be used versus how many people who do fossil rm followed by rm and fossil mv followed by mv. (I tried to make this point in my last mail, but I don't think people quite get what I'm trying to say). well, I dit get it (and that's why I started the thread in the first place): couldn't have summarized the actual question/problem at hand better (including that the apparent phobia that fossil might mercurialized, gittized, or what ever is completely beside the point and the 99.9% (or whatever) use case is what matters here). I'm completely surprised by the level of emotion this seemingly innocuous request/question to sanitize the default behaviour has created. hope people are going to calm down again soon. and I really don't get it that at the very least there could be any disagreement that a `fossil mv' without doing the same to the checkout is not a good default. joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 18:02:25 +0100, Marcelo richiead...@gmail.com wrote: 2012/12/13 Nolan Darilek no...@thewordnerd.info On 12/13/2012 08:40 AM, Marcelo wrote: They want the good things about fossil but they want to keep working as if it were Git. I say, if they like Git so much, eat the crow that comes with it. And that doesn't even make sense, either. If I wanted Git, then I'd use Git, full stop. It's silly telling me that changing this rm behavior is suddenly going to make Fossil so like Git that I'm all like Oh, great, now I've succeeded in my nefarious mission of making everything Git-like! Mine is an EVIL laugh! Next I'll ask for rebase! You may laugh at the image of the cackling, moustache twirling villain -- after all, I've used the image myself in hyperbole. But what you're deliberate neglecting is that rebase *has been requested already*, even when it goes against all what Fossil stands for. Not so silly any more, it seems. Making this sort of argument damages the cause because it puts those of us advocating for a thing in a position we aren't necessarily in, so it makes us want to just let the point go. I don't want Fossil to be another Git, but by telling me that I do, I'm suddenly either compelled to stop advocating for *any* change that violates Least Surprise. And hell, my example didn't even *use* Git's behavior to justify my claims and I'm *still* being told that OMG I want to make Fossil like teh gits! I respect the Fossil should be conservative arguments even though I disagree with them, but I'm going to call this exaggeration and hyperbole out on the carpet. Go ahead, call it whatever tickles your fancy. I'm not adverse to use exaggeration and hyperbole to make a point, and I accept I did. So what? it's annoying/exhausting. that's what. I don't think is a bad think to counter somewhat the impulse of advocating the full Git command line experience in Fossil just for the same of the muscle memory of some repentant Git users. really: why not stop this nonsense/aggressiveness? nobody needs this (yourself included I presume) Is fair to notice that the rm/mv issue is the one I have *less* objections about. Is the full cloning of command line options of other systems fine. that's what we are talking about. what's grating at my teeth right now. That and the advocacy for a rebase-like feature as The Only Right Way To Work With Source Code. I don't miss rebase right now (and yes: that feature exists out there in the wild (git, mercurial, probably others). personally, though, I find it rather easy to ignore unwanted features/commands. and I _know_ there are projects making good use of rebase without saying that other roads to not lead to Rome, too. you need not use it if you don't like it. it's not an evil feature per se. but again: I don't care for it, currently. 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] suggestion
On Tue, 20 Nov 2012 00:53:04 +0100, Themba Fletcher themba.fletc...@gmail.com wrote: On Mon, Nov 19, 2012 at 3:46 PM, Themba Fletcher themba.fletc...@gmail.com wrote: On Mon, Nov 19, 2012 at 3:12 PM, j. v. d. hoff veedeeh...@googlemail.com wrote: On Mon, 19 Nov 2012 22:49:22 +0100, Richard Hipp d...@sqlite.org wrote: On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: hi there, a modest suggestion: snip -- there seems no easy way to get a list of ignored files (as per the `fsl set ignore-glob' setting. in most cases I find that this setting should be part of the global state of the project. in `hg' there is a default file `.hgignore' where the glob patterns can be put. I find this most useful since in this way the ignore patterns can (but need not) be made part of the project state that is transfered to the other side. This should help: http://www.fossil-scm.org/index.html/doc/trunk/www/settings.wiki Grrr. sorry for the rtfm -- I meant to add more here but hit send instead At the very bottom of the page you'll find a general discussion about versionable settings and specific reference to the .fossil-settings/ignore-glob file, which is exactly what you're looking for I believe. thank you very much for this hint. I was not aware of this facility and, yes, it's essentially what I was looking for regarding making the ignore-glob settings an intrinsic property of the project. joerg Themba snip I'd like to emphazise: this sure is not a complaint but just expression of my opinion that the UI (and in turn adoption of `fossil') might profit from some changes. and I'd like to learn what the community thinks of these issues. are all of them irrelavant? Fossil was the first VCS that I used with any regularity. So, from that point of view, I find when I'm working with bzr, git, and particularly svn that they each seem really idiosyncratic and weird to me. So there's *a* point of view, for what little it's worth. I find fossil to be really scriptable, and over time I've either scripted over the pain points, learned to accept them, or as often as not learned to appreciate them. As a case in point, I too originally found the chattiness of the autosync cycle to be kind of irritating. Over time, however, I've found it provides a bit of peace of mind when the network gets slow or something else happens (unexpectedly large repo?) and I can clearly see that fossil's still doing or trying to do something. Compare git, where you just type git clone and wait, never knowing if you fat fingered the url or if you're slowly filling your drive with 40G of nonsense... Best regards, Themba j. regards, joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] suggestion
On Tue, 20 Nov 2012 01:13:51 +0100, Richard Hipp d...@sqlite.org wrote: On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: some more remarks from a new user: I've been trying out fossil only for the last two weeks or so. and coming from `mercurial' (and knowing `subversion' to some extent) I find the user interface quite idiosyncratic in places (such an impression was not caused when first using mercurial, e.g.): Constructive feedback is always appreciated. Thank you! User feedback is enormously important, and I do pay close attention to it. And Fossil has been greatly improved as a result of user feedback. Perhaps the most striking example of this is the change graph on the web timeline that was suggested by Andreas Kupries - I probably would not have thought of that on my own, and yet now I don't see how I ever survived without it. That said, please also recognize that I wrote Fossil because the other VCSes out there (or that were out there 7 years ago) did not meet my needs. And so one should not expect Fossil to be just like all the others. Fossil works how I want a VCS to work. If you find Fossil useful as well, that's cool tool, and I am happy to make reasonable accommodations for differing tastes. Even so, one should not expect Fossil to be like every other DVCS. That would defeat the purpose, no? sure right and that's definitely not my attitude. -- the sparse `fossil set' output I've mentioned already. -- `fossil stat, changes, info, extras': of course, there is no requirement to mimic `hg', `svn' or what else but the signal to noise ratio for the average user is quite low in my view. `stat' and `info' seem to differ only by the mostly irrelvant `project-name' entry while both reporting full lenghts SHA1 codes which mostly seem not to be needed here (well, I did not, up to now...). stat is (mostly) a combination of changes and info. mostly I would like to get information here whether there are changes (edits, adds, removals...) or not and what files are not tracked. `hg stat' does provide that. in fossil I have to do `fossil changes' _and_ `fossil extras'. That would not work well with my workflows, since I tend to keep lots of extraneous unmanaged files laying around, and I do not use ignore-glob. well, I do heavily so. So it would never occur to me to have a command that shows both changes to managed files and lists unmanaged files, all at the same time. In my check-outs, such a command is likely to drown the user in a list of unmanaged files that is so huge that it obscures the changes to managed files. on the contrary I find this very useful from my experience with `hg': first thing I do when putting some dir/procject under revision control, is set up the ignore-glob list (e.g. *.o or all the auxiliary files generated by `pdflatex'). than I do `fossil add .'. if in the course of the project new files are created but I forget to explicitely `add' them I do get a notification from `hg stat', listing untracked (not the ignored!), added, removed, modified files. from this list it's easy to decide whether untracked files have to be `add'ed or whether the ignore-glob pattern has to be extended. so, in a workflow where one _does_ make extended use of ignore-glob, such a listing will never be long. it only will be (as in your case, if, e.g. the *.o files are simply untracked, but not ignored. I hope you can see my point. since such a listing obiously collides with your own workflow: how about a long or comprehensive option for `changes' (which seems the neares equivalent to `hg stat') to make it put out the combined list of changed (!) tracked files and (not-ignored!) untracked files? Maybe we could invent a system whereby a user could create their own fossil commands to suite their own tastes? So you could define a site-specific fossil stat command that simply runs changes and extras in succession. Would that help? yes, I would something like that. this approach indeed works very well in `hg' in my view. (potential problems with overriding intrinsic commands have been mentionend in this thread already, but should be manageable in my view). -- there seems no easy way to get a list of ignored files (as per the `fsl set ignore-glob' setting. in most cases I find that this setting should be part of the global state of the project. in `hg' there is a default file `.hgignore' where the glob patterns can be put. I find this most useful since in this way the ignore patterns can (but need not) be made part of the project state that is transfered to the other side. -- fossil timeline: I find this really hard to read and use for at least two reasons: I seldom use fossil timeline, preferring instead to run fossil ui and look at the timeline with the graph in my web-browser. Am I the only one that thinks this way? I am sure you are not the only one
[fossil-users] why does `fossil rm' not do the real thing?
I already stumbled a couple of times over the fact that `fossil rm' and `fossil mv' only act on the repository but not on the check out, i.e. I always have to issue two commands in order to actually remove a file from the (future of) the project. obviously this is different from other VCSs but I'm missing the point why it is a good idea to decouple both actions (removal from tracking and actual removal). any enlightenment appreciated... right now I'd say it'd be better to keep the actions coupled. 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] why does `fossil rm' not do the real thing?
On Tue, 20 Nov 2012 15:00:29 +0100, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Nov 20, 2012, at 14:45 , Richard Hipp wrote: CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. This calls for making it a setting with a grace period of few releases before changing the default behavior... I'd second that. moreover, it's hard for me to see how real harm could be done. presuming that the last revision (or even the current) are part of the project history anyway an unintentional (as far as the respective old script is concerned) removal of the checked out file should not really be a problem, right? j. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] why does `fossil rm' not do the real thing?
On Tue, 20 Nov 2012 16:48:00 +0100, James Turner ja...@calminferno.net wrote: On Tue, Nov 20, 2012 at 03:39:06PM +, David Given wrote: Richard Hipp wrote: [...] CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. Add a -p for physical option to actually change the files, and leave the default as is? I agree, changing the existing behaviour would be a recipe for disaster. I'd suggest -f like cvs rm uses. obviously everybody seems to have his/her own preference how to handle this. so only a fraction of users will be happy in the end it seems. -- I would again second the proposal of Remigiusz Modrzejewski in this thread: after a 'grace' period when it would behave in the way you propose (explicitly add a -f flag to enforce deletion), finally change the default to what _current_ VCSs (= svn) seemingly all (?) do by default which is to treat `svn(hg, git, bzr) rm' as meaning remove from repository and also remove the working copy while relegating different behaviour (if at all) to an option such as bzr rm --keep. in my way that is the most frequently intended behaviour which should therefore be the default. sure a matter of taste as so many things, but at least it would avoid surprises here for refugees from one of the other systems. 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] [1.22] Easy way to cancel tentative changes?
On Fri, 16 Nov 2012 11:12:23 +0100, Gilles gilles.gana...@free.fr wrote: Hello This is a newbie question. Prior to using Fossil, to try something and still be able to go back in case the change didn't work, the only way I had was to comment things out. Now that I'm used to using Fossil, I just keep a DOS box open so I can easily run fossil.exe commit -m Some comment before making changes. However, in case the change didn't work, what is the best/easiest way to tell Fossil to forget about it and go back to the last commited version? Is fossil.exe revert myfile.txt OK? What about if changes involve multiple files? Will fossil.exe revert forget all the changes made to all the files, and fetch the latest commited versions from the repo so I can try something else? what is unclear about the help message for `revert': 8--- Usage: fossil revert ?-r REVISION? ?FILE ...? Revert to the current repository version of FILE, or to the version associated with baseline REVISION if the -r flag appears. Revert all files if no file name is provided. If a file is reverted accidently, it can be restored using the fossil undo command. Options: -r REVISIONrevert given FILE(s) back to given REVISION See also: redo, undo, update 8--- in effect `revert' pulls the specified file(s) (ar all, if no name is specified) out of the specified revision (or the *CURRENT* (usually the most recent checked in) one if none is specified) and replaces your working copies of the file(s) with them. so there are two slightly different situations: a) you change your file(s) and discover _before_ check in that the changes make no sense. in this case `fossil revert file(s)' resets the file content to that present in the CURRENT check in (that is prior to your false edits). b) you discover the changes didn't make sense too late, after (possibly multiple successive) check ins of buggy stuff. in this case you have to use `fossil revert -r [rev.id] file(s)' where rev.id. points to the last sane state of your files. note that once things are checked in `fossil' will not (and is not supposed to: that's mostly the point of such a system) forget the stuff. it remains part of the history, so you don't erase the erroneous stuff in the repository but put the corrected (or restored previous) version on top as a new check in. hth j. Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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 1.24 not working via ssh
I've tested this here (with Fossil-4473a27f3b6e049e) but can only report partial success: * it works using bash/ksh as login shell on the remote machine _if_ there is not too much text (the allocated buffer size (5) is still rather modest but usually sure sufficient) coming in from `.profile' over the ssh connection. so that's a clear step forward. however: * it does _not_ work if the default verbose (multi-line/blank line separated multi-paragraph, but much shorter than 5 bytes) ubuntu motd stuff comes in. the (visible) offending text looks something like this: 8-- Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-32-generic x86_64) * Documentation: https://help.ubuntu.com/ System information as of Mon Nov 12 13:20:41 CET 2012 System load: 0.04 Processes: 114 Usage of /: 72.3% of 9.96GB Users logged in: 2 Memory usage: 22% IP address for eth0: 123.456.78.90 Swap usage: 0% Graph this data and manage this system at https://landscape.canonical.com/ 0 packages can be updated. 0 updates are security updates. 8-- - what's strange is: if I copy this text into an `echo' command within `.profile' and then deactivate the MOTD (so seeminly getting the same stuff send over the ssh connection during login), it works flawlessly!?. my guess would be that there are some unprintable characters/escapes sent as well which I do not see so that copying the MOTD to `.profile' is not really the same thing as what is happening when ubuntu sends the stuff. * it also does _not_ work (with bash that is: ksh keeps working) if I myself send some escape sequences from my login scripts (as mentioned in a previous mail intended to dynamically adjust my xterm-titlebars). what's happening here is completely unclear to me, since it seems bash specific. what's worse: issuing the respective `echo' directly in the script instead of within a shell-function (as is usually done in my setup) does not lead to a failure. my setup might be somewhat esoteric here, so maybe it's not too important, but it indicates of course that there still is something fundamentally not OK. * and it does not at all work with tcsh as login shell on the remote machine (even if login is completely silent). in this case I get the error message tput: No value for $TERM and no -T specified TERM: Undefined variable. Fossil-4473a27f3b6e049e/fossil: ssh connection failed: [test1 probe-4f5d9ab4] so, seemingly `tcsh' users are out of luck anyway. questions: * maybe the (echo/flush) process has to be iterated one further time to make fossil happy with ubuntu's motd (after all it's not the least frequent linux distro)? * could fossil (or a debug version) not provide a (additional) hexdump (a la `hexdump -C' on linux) of the content of `zIn' instead of using `fossil_fatal(ssh connection failed: [%s], zIn);'? in this way one might be able to at least to recognize what exactly is coming in which might help in tracking down the source of the trouble: it need not be printable characters coming over the ssh connection after all. j. On Sun, 11 Nov 2012 23:44:31 +0100, Richard Hipp d...@sqlite.org wrote: On Sun, Nov 11, 2012 at 5:11 PM, Matt Welland estifo...@gmail.com wrote: I'll top-post an answer to this one as this thread has wandered and gotten very long, so who knows who is still following :) I made a simple tweak to the ssh code that gets ssh working for me on Ubuntu and may solve some of the login shell related problems that have been reported with respect to ssh: http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26v2=61f9ddf1e2c8bbb0 Not exactly the same patch, but something quite similar has been checked in at http://www.fossil-scm.org/fossil/info/4473a27f3b - please try it out and let me know if it clears any outstanding problems, or if I missed some obvious benefit of Matt's patch in my refactoring. Joerg iasked if this will make it into a future release. Can Richard or one of the developers take a look at the change and comment? Note that unfortunately this does not fix the issues I'm having with fsecure ssh but I hope it gets us one step closer. Thanks, Matt -=- On Sun, Nov 11, 2012 at 1:53 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Sun, 11 Nov 2012 19:35:25 +0100, Matt Welland estifo...@gmail.com wrote: On Sun, Nov 11, 2012 at 2:56 AM, j. van den hoff veedeeh...@googlemail.com**wrote: On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland estifo...@gmail.com wrote: sshfs is cool but in a corporate environment it can't always be used. For example fuse is not installed for end users on the servers I have access to. I would also be very wary of sshfs and multi-user access. Sqlite3 locking on NFS doesn't always
Re: [fossil-users] fossil 1.24 not working via ssh
On Mon, 12 Nov 2012 15:51:04 +0100, Richard Hipp d...@sqlite.org wrote: On Mon, Nov 12, 2012 at 8:36 AM, j. van den hoff veedeeh...@googlemail.comwrote: I've tested this here (with Fossil-4473a27f3b6e049e) but can only report partial success: * it works using bash/ksh as login shell on the remote machine _if_ there is not too much text (the allocated buffer size (5) is still rather modest but usually sure sufficient) coming in from `.profile' over the ssh connection. so that's a clear step forward. however: * it does _not_ work if the default verbose (multi-line/blank line separated multi-paragraph, but much shorter than 5 bytes) ubuntu motd stuff comes in. the (visible) offending text looks something like this: Please try again using http://www.fossil-scm.org/fossil/info/00cf858afe and let me know if the situation improves. If it still is not working, indeed it does: congratulation! * it now works without problems both with bash and ksh and does no longer choke on ubuntu's motd stuff (nor on 'my' escape sequences). putting excessively much text in the way still leads to a failure but that's probably rather a feature... * with tcsh, I most of the time get 8--- tput: No value for $TERM and no -T specified TERM: Undefined variable. Bytes Cards Artifacts Deltas Sent: 53 1 0 0 waiting for server... 8--- where it hangs infinitely (this is an extrapolation from the actually waited ~ 30 sec...) sporadically, however, it does not issue 'waiting for server' (or it's overwritten to quickly) and actually completes successfully. this might very well be a real tcsh issue (in which case one might contact the maintainers) but if this could reliably be handled as well I presume the problem is solved completely. here, several colleagues (not me any more) still stick with tcsh for interactive work and it quite probably still is the default shell on most BSD descendants (not on macosX, though). thanks a lot. please run with the --sshtrace command-line option and send me the diagnostic output. Thanks. I see the command in the source but it seems not to be recognized. how is it supposed to be called? 8**--** Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-32-generic x86_64) * Documentation: https://help.ubuntu.com/ System information as of Mon Nov 12 13:20:41 CET 2012 System load: 0.04 Processes: 114 Usage of /: 72.3% of 9.96GB Users logged in: 2 Memory usage: 22% IP address for eth0: 123.456.78.90 Swap usage: 0% Graph this data and manage this system at https://landscape.canonical.** com/ https://landscape.canonical.com/ 0 packages can be updated. 0 updates are security updates. 8**--** - what's strange is: if I copy this text into an `echo' command within `.profile' and then deactivate the MOTD (so seeminly getting the same stuff send over the ssh connection during login), it works flawlessly!?. my guess would be that there are some unprintable characters/escapes sent as well which I do not see so that copying the MOTD to `.profile' is not really the same thing as what is happening when ubuntu sends the stuff. * it also does _not_ work (with bash that is: ksh keeps working) if I myself send some escape sequences from my login scripts (as mentioned in a previous mail intended to dynamically adjust my xterm-titlebars). what's happening here is completely unclear to me, since it seems bash specific. what's worse: issuing the respective `echo' directly in the script instead of within a shell-function (as is usually done in my setup) does not lead to a failure. my setup might be somewhat esoteric here, so maybe it's not too important, but it indicates of course that there still is something fundamentally not OK. * and it does not at all work with tcsh as login shell on the remote machine (even if login is completely silent). in this case I get the error message tput: No value for $TERM and no -T specified TERM: Undefined variable. Fossil-4473a27f3b6e049e/**fossil: ssh connection failed: [test1 probe-4f5d9ab4] so, seemingly `tcsh' users are out of luck anyway. questions: * maybe the (echo/flush) process has to be iterated one further time to make fossil happy with ubuntu's motd (after all it's not the least frequent linux distro)? * could fossil (or a debug version) not provide a (additional) hexdump (a la `hexdump -C' on linux) of the content of `zIn' instead of using `fossil_fatal(ssh connection failed: [%s], zIn);'? in this way one might be able to at least to recognize what exactly is coming in which might help in tracking down the source of the trouble: it need not be printable characters
Re: [fossil-users] fossil 1.24 not working via ssh
On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland estifo...@gmail.com
wrote:
sshfs is cool but in a corporate environment it can't always be used. For
example fuse is not installed for end users on the servers I have access
to.
I would also be very wary of sshfs and multi-user access. Sqlite3 locking
on NFS doesn't always work well, I imagine that locking issues on sshfs
it doesn't? in which way? and are the mentioned problems restricted to NFS
or other file systems (zfs, qfs, ...) as well?
do you mean that a 'central' repository could be harmed if two users try
to push at the same time (and would corruption propagate to the users'
local repositories later on)? I do hope not so...
could well be worse.
sshfs is an excellent work-around for an expert user but not a
replacement
for the feature of ssh transport.
yes I would love to see a stable solution not suffering from interference
of terminal output (there are people out there loving the good old
`fortune' as part of their login script...).
btw: why could fossil not simply(?) filter a reasonable amount of terminal
output for the occurrence of a sufficiently strong magic pattern
indicating that the noise has passed by and fossil can go to work? right
now putting `echo ' (sending a single blank) suffices to let the
transfer fail. my understanding is that fossil _does_ send something like
`echo test' (is this true). all unexpected output to tty from the login
scripts would come _before_ that so why not test for receiving the
expected text ('test' just being not unique/strong enough) at the end of
whatever is send (up to a reasonable length)? is this a stupid idea?
On Sun, Nov 11, 2012 at 2:01 AM, Ramon Ribó ram...@compassis.com wrote:
Sshfs didn't fix the problems that I was having with fossil+ssh, or at
least
only did so partially.
Why not? In what sshfs failed to give you the equivalent functionality
than a remote access to a fossil database through ssh?
2012/11/11 Timothy Beyer bey...@fastmail.net
At Sat, 10 Nov 2012 22:31:57 +0100,
j. van den hoff wrote:
thanks for responding.
I managed to solve my problem in the meantime (see my previous mail
in
this thread), but I'll make a memo of sshfs and have a look at it.
joerg
Sshfs didn't fix the problems that I was having with fossil+ssh, or at
least only did so partially. Though, the problems that I was having
with
ssh were different.
What I'd recommend doing is tunneling http or https through ssh, and
host
all of your fossil repositories on the host computer on your web
server of
choice via cgi. I do that with lighttpd, and it works flawlessly.
Tim
___
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
--
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 1.24 not working via ssh
hi list, first time around: I've recently had a first look at fossil. it's mostly working as advertised but communication via ssh won't work. from going through the archives I get the impression that this is a rather long standing problem (~ years...) related to interfering output from the remote shell or wrong behaviour of tcsh or what else. my setting: I'm running fossil 1.24 on both my labtop (macbook) and the server (recent ubuntu). the server is _only_ accessible via ssh from the outside. what I tried up to now -- suppressed the annoying MOTD/login message generated by the server -- suppressed the Warning: No xauth data; using fake authentication data for X11 forwarding. message by adding the `-x' flag to fossil's ssh-command via `set'(i.e. fsl set ssh-command 'ssh -vvv -x -e none -T': I added `-vvv' to get some debug output from ssh, but omitting -vvv makes no difference) -- tentatively changed my login shell on the server from `tcsh' to `bash' when I login to the server (keys are set up so that no password has to be provided) from the command line with `ssh -x' I get a smooth login to the server -- no questions asked, nothing send to the terminal. when I try to clone a repository from the server I get what seemingly many have seen before one way or the other: $ fossil clone ssh://myserver/path_to_repository clone.fossil leads to this output: ssh -vvv -x -e none -T myserver OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011 ... debug1: Authentication succeeded ... ... debug2: shell request accepted on channel 0 fossil: ssh connection failed: [] debug2: channel 0: read=0 rfd 5 len 0 debug2: channel 0: read failed debug2: channel 0: close_read ... Killed by signal 2. I could not find _any_ working recipe on the net how to get it going. I would really appreciate if the ssh issue could get addressed by the developers. while I appreciate the http centric design of fossil, exclusive communication to secure servers via ssh is quite a general situation. out of the box usability of ssh thus seems to me mandatory for fossil to gain widespread acceptance (just my 2c, of course...) my specific question: could someone advise how I can make fossil happy with ssh (and me with fossil)? thx joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil 1.24 not working via ssh
On Sat, 10 Nov 2012 15:48:11 +0100, Richard Hipp d...@sqlite.org wrote: On Sat, Nov 10, 2012 at 9:43 AM, j. van den hoff veedeeh...@googlemail.comwrote: whoa! that's a quick reply ;-). I would really appreciate if the ssh issue could get addressed by the developers. It has my attention. I just don't know what to do about it. Do you have no offense meant (I was not implying no one cares..). any suggestions on how to improve the way the SSH method operates? unfortunately, no: I neither know too much ssh internals nor how fossil operates over ssh. I really spent quite some time these last days hunting around the net and did everything which was recommended (silencing the login, avoiding tcsh). ssh itself works fine (and does so, e.g., both with svn and mercurial) for me. from what I've read I was not able to understand what the problem really is: what is different in fossil's usage of ssh compared, e.g. to mercurial? I seem to understand that fossil is confused by chatty login messages, but I've got rid of them without the problem going away. what happens between the ssh message debug2: shell request accepted on channel 0 and fossil: ssh connection failed: [] could e.g. a `ssh-debug' flag be added to `fossil set' which enables a comprehensive log of relevant information (on the client side? on the server side?) to better understand what's going on? I would be happy to provide such logging information (as long as no privacy/security concerns are involved) or is the principle reason of failure known anyway? frequently, there are some searchpath issues (e.g. non-interactive vs. interactive shell, path updated/augmented at different places (system wide and local .bashrc .profile etc.)). maybe something like `fsl set path_to_remote_fossil' (or added to the ssh-command) could help to definitely get fossil started on the other side? just guessing, of course... joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil 1.24 not working via ssh
thanks for responding. On Sat, 10 Nov 2012 17:53:40 +0100, Martin Gagnon eme...@gmail.com wrote: On Sat, Nov 10, 2012 at 9:48 AM, Richard Hipp d...@sqlite.org wrote: On Sat, Nov 10, 2012 at 9:43 AM, j. van den hoff veedeeh...@googlemail.com wrote: I would really appreciate if the ssh issue could get addressed by the developers. It has my attention. I just don't know what to do about it. Do you have any suggestions on how to improve the way the SSH method operates? I think someone have proposed the ideal solution previously in this list (I didn't find it on the mailing list archive, yet) It would be to execute directly fossil throught ssh with a new fossil command which would act similar as fossil test-http, except that it would process all chunks of sync data until the whole sync/push/pull is completed. That way fossil on local side would be directly connected to the remote fossil pipe and nothing from shell or login session could be in the way. Let say the new fossil command is: fossil ssh-http So instead of invoking: ssh -T -e none remotehost, fossil would do: fossil remotehost fossil ssh-http When specifying a command to the ssh command line, stdin and stdout are directly connected to the invoked command, so you cannot have gargabe between. I beleive it's how other scm use ssh... thanks for clarifying. I did some further testing and finally managed to make my setup compliant with fossil's demands. I consider to be the following describing the state of affairs (valid for a recent +bash+ on recent ubuntu -- with +tcsh+ it seems not to work anyway): * fossil does indeed an interactive ssh login. that implies - the user's +.profile+ is processed (in agreement with the +bash+ manpage) - the user's +.bashrc+ is _not_ processed (seemingly in _disagreement -- if I read it correctly -- with the +bash+ manpage) * after +.profile+ is processed, +fossil+ needs to be on the search path. setting the path in +.bashrc+ is too late * _any_ tty ouput during the login procedure must be strictly prevented either from the system (MOTD) or from +.profile+ - at least on ubuntu the former (system message) can be prevented by doing +touch .hushlogin+ in the user's home directory. - the former (tty output from +.profile+) can occur in unexpected (for me at least) ways, even unprintable characters can do harm: for instance, in my interactive setup I put the name of the working directory in the title bar of the terminal automatically after each cd by using the corresponding xterm escape sequences. this is done, too, in .profile in order to immediately have the correct title bar. the catch is: these escape sequences are send to stdout just like text and so they prevent fossil from working correctly. but funny enough, this is only the case for +bash+: with +ksh+ sending these escape sequences does no harm (while echoing a single blank still does). my conclusion is: it is rather unfortunate that +fossil+ relies on a bare bones interactive set up of the user's account. minor fiddling with the setup can break everything. I would say the bottom line from the above obviously is that using interactive login is really fragile: (and I believe that's what you were saying in the first place, right?). if it's true that the other scm avoid this problem by avoiding interference of the shell, than that sure is better in my view (as already stated: despite the fancy escape sequences produced in my login scripts, +svn+ and +hg+ don't care at all and just work -- with tcsh, too). I'm nevertheless happy that I can report the problem to be solved for me: in the end using +ksh+ as login shell on the remote machine for now seems the best solution for me (since with bash fossil still chokes on the mentioned escape sequences). what I would think to be a good idea (as long as no real solution is in place): to put a clear howto make syncing over ssh work on the fossil webpage clearly stating that the login has to be _absolutely_ silent and that (seemingly) only bash and ksh (zsh, too?) work, but tcsh doesn't. might save new users like me a lot of time in the future and provide on average better initial experience with +fossil+ ;-). good luck joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil 1.24 not working via ssh
thanks for responding. I managed to solve my problem in the meantime (see my previous mail in this thread), but I'll make a memo of sshfs and have a look at it. joerg On Sat, 10 Nov 2012 21:04:07 +0100, Ramon Ribó ram...@compassis.com wrote: Hello, One simple solution, if using Linux, is sshfs. It creates a remote file system in the local computer. Then, You can sync as if the remote file were a local file. It works nicely. Maybe the fossil ssh implementation can get some ideas from this package. Ramon Ribó 2012/11/10 Martin Gagnon eme...@gmail.com On Sat, Nov 10, 2012 at 2:18 PM, Richard Hipp d...@sqlite.org wrote: On Sat, Nov 10, 2012 at 11:53 AM, Martin Gagnon eme...@gmail.com wrote: On Sat, Nov 10, 2012 at 9:48 AM, Richard Hipp d...@sqlite.org wrote: On Sat, Nov 10, 2012 at 9:43 AM, j. van den hoff veedeeh...@googlemail.com wrote: I would really appreciate if the ssh issue could get addressed by the developers. It has my attention. I just don't know what to do about it. Do you have any suggestions on how to improve the way the SSH method operates? I think someone have proposed the ideal solution previously in this list (I didn't find it on the mailing list archive, yet) It would be to execute directly fossil throught ssh with a new fossil command which would act similar as fossil test-http, except that it would process all chunks of sync data until the whole sync/push/pull is completed. http://www.fossil-scm.org/fossil/artifact/935bc0a983135b?ln=192 That's what the current code does. Any ideas on how to make it more robust in the face of varying SSH implementations? I think the problem is that now, it use the shell, it doesn't call fossil on the remote side directly from the ssh command line. To be more robust, the test-http command (more precicely the new command I call ssh-http in my example) should be append to zCmd here: http://www.fossil-scm.org/fossil/artifact/935bc0a983135b?ln=154 That will connect stdin and stdout *directly* to the remote fossil command. If you do that, you don't need to care about shell and login noise. *But* in that case, fossil on remote side will have to handle the whole sync operation by himself.. (it's like the ssh-http command call what test-http does multiple time). (for what I understand from what test-http does) [snip] -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
