[fossil-users] `fossil finfo -b' is slightly misbehaving (bug?)
hi, I want to report the following observation: `finfo -b' is supposed to produce one-line abbreviations for all commits but in fact introduces spurious line breaks which put a single trailing word (or some chars) on the next line. example: doing fossil finfo -b BUILD.txt in the Fossil repo itself yields 8 d5f6e08c09 2013-06-10 drh ipv6 Merge all the latest trunk changes into 940b0b33c9 2013-04-21 ashish ashish-i Merge with trunk - Remove reverse-proxy f4b082d464 2012-10-09 viriketo annotate Updating from trunk. I solved some merge --- spurious abbc00fc5b 2012-08-24 jan.nijt eclipse- Merge in the mingw build enhancements 4e93e84e55 2012-08-24 jan.nijt trunk wiki tweaks regarding MinGW build enhanc 75aaf30aad 2011-08-30 viriketo merge_re Updating from trunk to keep up working i --- spurious c57830bec2 2011-08-22 dmitry symlinks Merge trunk. 84e6f172af 2011-08-16 venkat venks-em update branch before making changes 8 In case this e-mail wraps, I've marked the spurious lines where `merge' and `i' are erroneously wrapped by `fossil' to the next line. this happens with 1.26. in terms of what `fossil help finfo' says this seems to be bug... regards, joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New user request
Hi Sam. Welcome aboard. I think Fossil is excellent, and I hope you will too. I'm typing on a mobile device ATM, so please excuse the brevity and spelling errors. I use fossil for all my personal projects, as well as professionally. For personal projects, I make a project-specific dir under my project containing dir (~/work), such as ~/work/foo/, and create an out-of-tree repo: cd ~/work/foo; fossil new ../fossils/foo.fsl; fossil open ../fossils/foo.fsl . Then, in the project dir I make ./doc, ./src/vendor, ./test. Supporting third-party code goes into ./src/vendor/libawesome (for example), my own code goes into ./src, docs to ./doc, and tests to ./test. For an imaginary lib awesome project that I want to build against, I place the code in ./src/vendor/libawesome, fossil add ./src/vendor, then commit it to it's own branch: fossil ci -m libawesome v.1.2.3 --branch vendor For my own code, infrastructure, I go back to trunk (fossil co trunk), add my files: (cd ~/work/foo; fossil add ./Smakefile ./src/*.c ./src/*.h.in) and do initial commit: fossil ci -m initial commit. If you feel you need/may patch your vendor code, you can: fossil co vendor; [hack hack hack]; fossil ci -m custom patches against lib awesome for project foo --branch vend_patched -- and maintain this along with upstream lib awesome updates: fossil co vendor; [dump lib awesome v1.2.4 code over 1.2.3]; fossil ci -m update lib awesome 1.2.3 - 1.2.4 Import to vend_patched: fossil co vend_patched; fossil merge vendor; [check for conflicts, correctness], fossil ci -m merge latest lib awesome 1.2.4 from [vendor] Back to the code your writing yourself: fossil co trunk; fossil merge vend_patched; fossil ci -m import supporting vendor code; [hack hack hack]; fossil ci -m my useful commit msg here; [hack hack hack] ... now you (still on [trunk]) want to start on a potentially build-breaking experimental feature: a bunny themed widget set. Start hacking in bunny-code, but at first commit: fossil ci -m start of bunny conversion --branch hop_hop You've now got two branches that are interesting to you: current stable production in [trunk], and the Next Big Killer Feature (not ready for prime time), in hop_hop. You hack on [hop_hop] (which is a derivative of [trunk], and improve it. Along the way though, your boss says: I've heard lowercase is the new black; make all the dialogue in our current project lowercase. No title case, upper case, camel case... All user facing text is lowercase. [hop_hop] is still WIP (work in progress), not ready for public consumption, so you go back to [trunk] (which you are shipping). You're in the middle of hacking [hop_hop], and you're not really ready to commit, but you don't want to lose your work. No problem. Stash it. fossil stash add -m hop_hop fluffy tail feature - incomplete Your work is safe in a stash that is shared among all branches, and you have no pending commits in your working set (you just stashed it, and when that partial work was stashed, the pertinent files were reverted to the state of the last commit.) You prepare to start lowercasing: fossil co truck; [hack hack hack]; fossil ci -m lowercase here, lowercase there, and change all user dialogue, etc to lowercase, committing as you convert. You tag a new release: fossil tag add foo_5.4.3 trunk, notify q/a and release management, and get back to bunny hacking. fossil co hop_hop You start making a game plan for finishing fluffy tail feature, when you realize that the super-awesome lowercasing you just finished isn't in your hop_hop codebase. No problem: fossil merge foo_5.4.3; [check work for conflicts, nice importing]; fossil ci -m import lowercase excellence from [foo_5.4.3] Now, pick up your partial fluffy tail implementation: fossil stash pop (pops last stashed item like a stack operation), and you're ready to finish your interrupted coding and finish bunnifying. As you finish coding and commit, your boss comes up and says: What have you been working on these last 3 weeks? I'll show you, you say! fossil server [Open Firefox or opera, or chrome, etc], http://127.0.0.1:8080/ You are taken to the Foo Project Repository homepage, and from there you browse the timeline which has a pretty layout of each commit, each branch, each merge, each tag... Your boss is impressed. I'm impressed. But I want to give you some feature requests we've collected from clients. Would you like them as a crumpled collection of post it notes, or some other format? You say: Point your IE4 browser to 192.168.0.99:8080/, log in as superboss like I showed you, and add each item as a feature-request ticket, so we can all see the requests, and their state, and append notes to each feature as necessary. OK, says your boss, a glob of post it notes trying to break out of their pocket as they head back to the bosses computer to key in tickets... I could go on (I think I will, later), but I'm tired and I'm wearing a hole in my touch screen. I sure hope this provided some
[fossil-users] fossil clone question
hi, `fossil help clone' tells me: 8-- By default, your current login name is used to create the default admin user. This can be overridden using the -A|--admin-user parameter. 8-- I just tried that locally (within my file system): fossil clone -A JoeDoe orig.fossil clone.fossil 1. in `orig.fossil' the (sole) `setup' user is me (current_login_name), which is as it should be. (as an aside: the help text does speak of `admin' user, but actually its the `setup' user (and a `admin' user has different (somewhat lower) permissions) -- so this might call for a change of the help text?) 2. but in `clone.fossil' the web interface tells me that there are two `setup' users: current_login_name and JoeDoe question: should I expect this (I did not...)? I would have thought that there will be a single one (JoeDoe). and that is also what I intend to get... 3. a partly related question: I'm not 100% sure what are the implications of sending a fossil repository file to someone else. I know that the user/password information is in the sqlite database and that one can easily get at the passwords. my question is: if I don't care that the locally used user names are becoming known and the passwords are irrelevant/not valuable either: are there any more points to consider, i.e. is there anything else in the database which one should not distribute just so? thanks in advance for any enligthenment. 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] fossil clone question
Thus said j. van den hoff on Thu, 08 Aug 2013 09:31:28 +0200: 1.in `orig.fossil'the(sole) `setup'user isme (current_login_name), which is as it should be. (as an aside: the help text does speak of `admin' user, but actually its the `setup' user (and a `admin' user has different (somewhat lower) permissions) -- so this might call for a change of the help text?) Minor issue but should probably be clarified. 2. but in `clone.fossil' the web interface tells me that there are two `setup' users: current_login_name and JoeDoe question: should I expect this (I did not...)? I would have thought that there will be a single one (JoeDoe). and that is also what I intend to get... Either the text is wrong, or the behavior is wrong. One of them must be fixed. I believe it is not creating a new user that matches your login, but rather is preserving the user that exists in the source fossil, perhaps it is related to this comment I made: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12524.html You are doing a file clone. Other types of cloning do not do this: $ fossil clone -A someone ssh://remote//tmp/test.fossil new.fossil ... project-id: 78f3c64bd97f33cb0a7606842ca83ddf25776819 admin-user: someone (password is 2c9149) $ fossil user -R new.fossil list anonymousAnon developerDev nobody Nobody reader Reader someone ... if I don't care that the locally used user names are becoming known and the passwords are irrelevant/not valuable either: are there any more points to consider, i.e. is there anything else in the database which one should not distribute just so? Email addresses. Private branches in the repository. IP addresses. There is an option to scrub the fossil of sensitive info. fossil help scrub Andy -- TAI64 timestamp: 400052034eb3 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] cmdline arguments for repopsitory are inconsequent
on some commands one has to use -R repo e.g. sync pull push and others not clone ui server -R seems redundant. -- Rene ___ 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] cmdline arguments for repopsitory are inconsequent
On Thu, Aug 8, 2013 at 10:47 AM, Rene renew...@xs4all.nl wrote:
-R seems redundant.
It's not _entirely_ redundant - in some cases it changes how the arguments
are processed. Yes, there are inconsistencies there, but some of the
argument handling relies on one or the other approach. When the app looks
for a CLI flag, e.g. -R, fossil actually removes that flag and its argument
from the global argument list, which changes the argument count, and many
of the commands use logic like if(g.argc==3){...}, so there non-obvious
side effects when changing whether a command expects -R or not. It the
context of libfossil, that's been one of the minor points on the list of
things to consider, and while i don't much care for inconsistency in
software, i _think_ that i'll end up doing it similar to how it is done
now. e.g. a clone implies a -R (but normally in the form of a URL), and
doesn't need a flag. The commands you listed where -R is optional almost
always derive their repo db from the current checkout (which is why -R is
not required). i'm not sure why ui/server don't require -R, but instead
take their repo filename as a non-flag argument. Historical in nature, i
guess.
--
- 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] cmdline arguments for repopsitory are inconsequent
On Thu, 08 Aug 2013 10:58:58 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Aug 8, 2013 at 10:47 AM, Rene renew...@xs4all.nl wrote:
-R seems redundant.
It's not _entirely_ redundant - in some cases it changes how the
arguments
are processed. Yes, there are inconsistencies there, but some of the
argument handling relies on one or the other approach. When the app looks
for a CLI flag, e.g. -R, fossil actually removes that flag and its
argument
from the global argument list, which changes the argument count, and many
of the commands use logic like if(g.argc==3){...}, so there non-obvious
side effects when changing whether a command expects -R or not. It the
context of libfossil, that's been one of the minor points on the list of
things to consider, and while i don't much care for inconsistency in
software, i _think_ that i'll end up doing it similar to how it is done
just my 2c: I _do_ care for inconsistencies in the CL user interface and
the
-R thing is one of them: I always can only partly remember when it's
required
and when not. I'm sure there are reasons why it is the way it is. but I at
least
would consider it a relevant step forward if the CLI would be made more
consistent.
by and then I have complained about this in the past already.
e.g, the mixing of
-c
--c
-word
--word
style options was/partly is another issue. I would argue for reducing it
to -c and --word, probably, which would
also allow to tolerate omission of the blank between short option letter
and its argument
as in fossil diff -r1234 (just like with most unix commands). I've just
checked: it seems (is this true?) that this
problem is now only present with `fossil help' where in fact you have
`--c' and `-word' type options
while otherwise it seems to be already `-c' and `--word'.
a further small issue is that
on the one hand fossil has the necessary logic to accept unique partial
matches of commands
(e.g. `fossil info' vs. `fossil inf' (both OK) vs `fossil in' (ambiguous))
but apparently
none to do the same for long options. could the partial match logic not be
extended to long options?
overall, for some people I'm sure these sort of things are not less
important than a nice GUI. ;-)
j.
now. e.g. a clone implies a -R (but normally in the form of a URL), and
doesn't need a flag. The commands you listed where -R is optional almost
always derive their repo db from the current checkout (which is why -R is
not required). i'm not sure why ui/server don't require -R, but instead
take their repo filename as a non-flag argument. Historical in nature, i
guess.
--
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 clone question
On Thu, 08 Aug 2013 09:53:52 +0200, Andy Bradford amb-sendok-1378540432.bggbdoanfmpdfnjoo...@bradfords.org wrote: Thus said j. van den hoff on Thu, 08 Aug 2013 09:31:28 +0200: 1.in `orig.fossil'the(sole) `setup'user isme (current_login_name), which is as it should be. (as an aside: the help text does speak of `admin' user, but actually its the `setup' user (and a `admin' user has different (somewhat lower) permissions) -- so this might call for a change of the help text?) Minor issue but should probably be clarified. sure minor but a question of consistency. the option is even named `--admin-user'. easiest way to fix it might be a different naming scheme in the GUI setup user -- admin user admin user -- whatever 2. but in `clone.fossil' the web interface tells me that there are two `setup' users: current_login_name and JoeDoe question: should I expect this (I did not...)? I would have thought that there will be a single one (JoeDoe). and that is also what I intend to get... Either the text is wrong, or the behavior is wrong. One of them must be fixed. I believe it is not creating a new user that matches your login, but rather is preserving the user that exists in the source fossil, yes, that's probably the case. perhaps it is related to this comment I made: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12524.html You are doing a file clone. Other types of cloning do not do this: $ fossil clone -A someone ssh://remote//tmp/test.fossil new.fossil ... project-id: 78f3c64bd97f33cb0a7606842ca83ddf25776819 admin-user: someone (password is 2c9149) $ fossil user -R new.fossil list anonymousAnon developerDev nobody Nobody reader Reader someone I see. I would argue that the file system based clone should behave the same: if I explicitly specify a non-default admin-user that should be the exclusive one after in the clone. ... if I don't care that the locally used user names are becoming known and the passwords are irrelevant/not valuable either: are there any more points to consider, i.e. is there anything else in the database which one should not distribute just so? Email addresses. Private branches in the repository. IP addresses. There is an option to scrub the fossil of sensitive info. fossil help scrub thanks for this tip. I was not aware of that. j. Andy -- 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] cmdline arguments for repopsitory are inconsequent
On Thu, 08 Aug 2013 12:23:56 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Aug 8, 2013 at 12:14 PM, Stephan Beal sgb...@googlemail.com wrote: Sorry for the confusion: don't much care for is another way of saying do not like, and we agree completely that these inconsistencies are not ideal. Minor clarification for the non-native speakers: don't care FOR' means do not like, but do not care ABOUT means do not have strong feelings regarding... thanks. must have been sleeping in school when that difference was explained ;-) so, sorry for the noise. -- 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] incomplete documentation?
On Thu, Aug 8, 2013 at 1:38 PM, j. van den hoff veedeeh...@googlemail.comwrote: question: should there not be a help page for fossil itself, maybe (`fossil help fossil') which explains this sort of things? Is this perhaps what you're looking for: [stephan@host:~]$ f help help Usage: f help COMMAND or: f COMMAND -help Display information on how to use COMMAND. To display a list of available commands one of: f help Show common commands f help --a|-all Show both common and auxiliary commands f help --t|-testShow test commands only f help --x|-aux Show auxiliary commands only f help --w|-www Show list of WWW pages ? -- - 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?
I would agree here, it's not at all clear. Even when you know there is a --user option, then the fossil output isn't clear: steves@sapphire ~ f ls fossil: current directory is not within an open checkout # OK steves@sapphire ~ f --user foo fossil: fossil: unknown command: --user fossil: use help for more information # So the first argument must be the command? steves@sapphire ~ f --user foo ls fossil: current directory is not within an open checkout # No, it accepts user, maybe it accepts anything.. steves@sapphire ~ f --bar foo ls fossil: fossil: unknown command: --bar fossil: use help for more information # No, ok, so let's see the help: steves@sapphire ~ f --help Usage: fossil help COMMAND Common COMMANDs: (use fossil help --all for a complete list) add changes finfo merge revert tag addremove clean gdiff mv rm timeline all clone helpopensettingsui annotatecommit import pullsqlite3 undo bisect diffinfopushstash update branch export initrebuild status version cat extras ls remote-url sync This is fossil version 1.25 [d2e07756d9] 2013-02-16 00:04:35 UTC No mention.. what about fossil help user .. no, that's something else.. The same thing happens with -R, I believe Thanks Steve On Thu, Aug 8, 2013 at 1:27 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Thu, 08 Aug 2013 14:03:42 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Aug 8, 2013 at 1:38 PM, j. van den hoff veedeeh...@googlemail.com**wrote: question: should there not be a help page for fossil itself, maybe (`fossil help fossil') which explains this sort of things? Is this perhaps what you're looking for: [stephan@host:~]$ f help help Usage: f help COMMAND or: f COMMAND -help Display information on how to use COMMAND. To display a list of available commands one of: f help Show common commands f help --a|-all Show both common and auxiliary commands f help --t|-testShow test commands only f help --x|-aux Show auxiliary commands only f help --w|-www Show list of WWW pages ? no: `fossil --user joedoe ci' has the form fossil fossil_option COMMAND COMMAND_option so the possibility of having a option for fossil itself is not explained in the help. or what am I missing? what I mean is, in my understanding the terminology is COMMAND is one of the keywords (without leading dashes) displayed by `fossil help -a' while `--user' is not a COMMAND but rather an option (but not of one of the COMMANDS but of `fossil' itself. -- 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 ___ 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] best practices during a large rewrite
On Wed, Aug 7, 2013 at 11:23 PM, Themba Fletcher themba.fletc...@gmail.com wrote: Hi all, I recently got a contract to rewrite a large (web) application. The intent is to transition, at a measured pace, from a large collection of hand-written, framework-free php files to a structured setup with a nice MVC framework, etc. So far so good. I've got all the original source in a fossil repo and it has a pretty rich history as I've been maintaining this system for the last year or so. Moving this to the framework I've chosen will involve, up front, moving every single one of the exisiting source files to a new location deeper in the project hierarchy. The files will then be slowly replaced as their functionality is added to the new system in the appropriate place. I'd love to be able to do this project with hotfixes continuing on trunk as the deployed version evolves and having all of the restructuring take place on a super massive v2 branch, but I'm anticipating a few problems: * Merging updates from trunk to v2 -- cherrypick isn't going to work very well when the names don't match anymore, is it? * What should I expect after I've deleted a file on v2 (having replaced its functionality) and then merge back some updates from trunk containing a change to that file? Just a plain old merge conflict or should I expect and watch for the file to reappear on the branch after being previously deleted? * Anything else you can foresee? Why cherrypick? The simplest workflow here is, as you mention, develop new stuff in a v2 branch and fix bugs in trunk. The key secret here is the mantra: merge soon, merge often. I must admint that I haven't used Fossil long enough but what I would expect from Fossil is to give me a hard time the first time I merge from v2 to trunk, and straightforward merges the following times. Take the following example: A B trunk --o--o---o---o \ \ v2 ---o---o--o--o--o--o--o---o--o--o--o C DE F Assume that D is the first merge and is the hell of a merge. The next merge (which joins B and E) will have A as the common ancestor. So, unless you hit a bug in Fossil, merge F is only about incorporating the changes between A and B into the v2 branch. Merge F then makes B the common ancestor for the next merge. The advantage here is that, when v2 is ready for primetime, you just have to merge v2 into trunk and it should be a trivial merge too. In short, just follow these rules: - Don't cherrypick. - Always merge trunk into v2. That is: checkout v2 and, from there, merge trunk. This way the merge is committed as part of the v2 branch. When v2 is finished, proceed inversely. - Don't let the trunk with a leaf for too long. Remember: merge soon, merge often. The v2 branch should host most of the development activity, so merges will not be so abundant. - Personal advice, use a graphical merge tool (e.g. kdiff3). Fossil can be configured to resolve conflicts with them; otherwise, I wouldn't even be writing this. Has anyone out there tried a complete project restructuring on a branch with any success, or is the default workflow to just spin up another repo and synchronize changes by hand? Any other thoughts or input? I have successfully performed some heavy refactorings with this workflow a couple of times now, but with Mercurial. As I said, I would expect Fossil to work the same in this workflow because it is a very simple one: no criss-cross merges, no cherrypicking and the resulting history is beautifully clean. I hope it helps. Best regards. -- Isaac Jurado The noblest pleasure is the joy of understanding Leonardo da Vinci ___ 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 Thu, Aug 8, 2013 at 2:32 PM, Stestagg stest...@gmail.com wrote: I would agree here, it's not at all clear. Even when you know there is a --user option, then the fossil output isn't clear: In Fossil's defense: i've been using Fossil almost daily since Christmas 2007 and haven't every used --user. steves@sapphire ~ f --user foo fossil: fossil: unknown command: --user fossil: use help for more information IIRC, only commands which use user details (e.g. a commit or tag) allow/user a user override option. Most locally-run commands don't care who you are. # So the first argument must be the command? steves@sapphire ~ f --user foo ls fossil: current directory is not within an open checkout Unfortunately, that depends on the exact command :/. Side effects of the argument resolution process change (potentially) in what order some code must be run. i don't recall off-hand whether the top-level command dispatcher skips over --flags, but i don't see how it could because it cannot generically know if the token after a -flag is the value for the flag or if it is a command (unless it looks up the argument in its command table). i'm not in any way discounting your arguments that the help could be clearer/more intuitive in places, but some of the current behaviours are side effects of old design decisions which cannot simply be swapped out. Feel free to propose new/improved help texts :). -- - 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?
On Thu, 08 Aug 2013 17:00:08 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Aug 8, 2013 at 2:32 PM, Stestagg stest...@gmail.com wrote: I would agree here, it's not at all clear. Even when you know there is a --user option, then the fossil output isn't clear: In Fossil's defense: i've been using Fossil almost daily since Christmas 2007 and haven't every used --user. there was no attack so there need not be any defense ;-) steves@sapphire ~ f --user foo fossil: fossil: unknown command: --user fossil: use help for more information IIRC, only commands which use user details (e.g. a commit or tag) allow/user a user override option. Most locally-run commands don't care who you are. # So the first argument must be the command? steves@sapphire ~ f --user foo ls fossil: current directory is not within an open checkout Unfortunately, that depends on the exact command :/. Side effects of the argument resolution process change (potentially) in what order some code must be run. i don't recall off-hand whether the top-level command dispatcher skips over --flags, but i don't see how it could because it cannot generically know if the token after a -flag is the value for the flag or if it is a command (unless it looks up the argument in its command table). i'm not in any way discounting your arguments that the help could be clearer/more intuitive in places, but some of the current behaviours are side effects of old design decisions which cannot simply be swapped out. Feel free to propose new/improved help texts :). well that's sort of difficult for the average user I'd say since he does not _know_ what the parser is doing and what the set of valid calls to fossil looks like. I cannot be sure, for instance that there are no further undocumented `--word' options beside `--user' ... what about extending the output of `fossil help' by giving the most general syntax like fossil ?fossil_option(s)? COMMAND ?command_option(s)? (or whatever is correct) and listing the `fossil_options' here together with the list of valid commands with which they can be combined? if it only relates to `--user' this should be more or less easy for the people in the know (not me...). but more formally, it looks to me that it would be better to eliminate `fossil_options' altogether and add them as command_options to the respective command(s). that would make for a clearer and less unusual syntax overall. would that be difficult? 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] incomplete documentation?
On Thu, Aug 8, 2013 at 5:13 PM, j. van den hoff veedeeh...@googlemail.comwrote: well that's sort of difficult for the average user I'd say since he does not _know_ what the parser is doing and what the set of valid calls to fossil looks like. I cannot be sure, for instance that there are no further undocumented `--word' options beside `--user' ... lol! touché. i often forget that not everyone who uses fossil hacks on it :/. fossil ?fossil_option(s)? COMMAND ?command_option(s)? Because it would be a lie sometimes :/. The ordering of the flags and commands may or may not be important for a given command. _Normally_ it doesn't matter where the flags appear but it can if the one who implements that command isn't aware of the side-effects that argument parsing has on the list of arguments (as i wasn't when i started work on the JSON API). As a rule of thumb, the following syntax should work just about everywhere (if not everywhere): fossil command ?options? where ?options? can be command-specific or (quasi-)global (like -R). looking over the current output now: stephan@tiny:~/cvs/fossil/f2$ f help Usage: f help COMMAND ... i wouldn't expect ?options? to appear there, but that's probably a matter of personal taste (and mine is often in the minority ;). In your opinion, what should the top-level 'help' command say which it does not already? If we then go one level deeper for a specific command: stephan@tiny:~/cvs/fossil/f2$ f help ls Usage: f ls ?OPTIONS? ?VERSION? ?FILENAMES? ... that one has, IMO, pretty good help. There are certainly others which could be improved, but i don't have an example off the top of my head. But i did just discover the 'cat' command - i don't think i knew about that one before now. but more formally, it looks to me that it would be better to eliminate `fossil_options' altogether and add them as command_options to the respective command(s). that would make for a clearer and less unusual syntax overall. would that be difficult? In general that's what currently happens, e.g.: stephan@tiny:~/cvs/fossil/f2$ f help cat Usage: f cat FILENAME ... ?OPTIONS? ... Options: -R|--repository FILE Extract artifacts from repository FILE -R is one of those quasi-global options which is supported almost everywhere, but not all of the commands explicitly mention it (possibly the author of the command doesn't even realize it because it happens one level removed from his command). http://fossil-scm.org/index.html/artifact/0adc1aa79c24d8bc88b32e2ef7a8f29d32619d79?ln=1055 i don't personally hold out much hope of any groundbreaking changes in fossil's help system because it's literally integrated with the source code (the help text and command/page names are extracted from source code comments during the build process) and it works relatively well (and is very non-intrusive on the developers). That said, FWIW, i will certainly take your points to heart when libfossil[1] is far enough along that applications can be built off of it. My plan is to provide a skeleton CLI app mini-framework which does the bootstrap part of handling the -R flag, seeing if $PWD is part of a checkout, processing CLI flags, and exposing the CLI flags to the application in a higher-level form. That's still likely several months away, but maybe it'll give you some hope for a more consistent help system in future fossil-related products :). [1] http://fossil.wanderinghorse.net/repos/f2/ -- - 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?
One of the problems is that the help given by fossil help command isn't always complete. For example the help for checkin (fossil help ci), doesn't list the --date-override or --user-override options, even though they appear to be accepted. The same appears to be the case for the branch command. The only way I've found to discover them is to use grep find_option on the source - I'm not sure that is very user-friendly. ___ 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 finfo -b' is slightly misbehaving (bug?)
Thus said j. van den hoff on Thu, 08 Aug 2013 08:31:04 +0200: `finfo -b' is supposed to produce one-line abbreviations for all commits but in fact introduces spurious line breaks which put a single trailing word (or some chars) on the next line. This would appear to be a bug in the behavior. The following patch fixes it: Index: src/finfo.c == --- src/finfo.c +++ src/finfo.c @@ -196,11 +196,11 @@ blob_reset(line); blob_appendf(line, %.10s , zCiUuid); blob_appendf(line, %.10s , zDate); blob_appendf(line, %8.8s , zUser); blob_appendf(line, %8.8s , zBr); -blob_appendf(line,%-40.40s\n, zCom ); +blob_appendf(line,%-38.38s\n, zCom ); comment_print(blob_str(line), 0, 79); } } db_finalize(q); blob_reset(fname); Results: $ ./fossil finfo -n 10 -b BUILD.txt d5f6e08c09 2013-06-10 drh ipv6 Merge all the latest trunk changes int 940b0b33c9 2013-04-21 ashish ashish-i Merge with trunk - Remove reverse-pro f4b082d464 2012-10-09 viriketo annotate Updating from trunk. I solved some mer abbc00fc5b 2012-08-24 jan.nijt eclipse- Merge in the mingw build enhancements 4e93e84e55 2012-08-24 jan.nijt trunk wiki tweaks regarding MinGW build enha 75aaf30aad 2011-08-30 viriketo merge_re Updating from trunk to keep up working c57830bec2 2011-08-22 dmitry symlinks Merge trunk. 84e6f172af 2011-08-16 venkat venks-em update branch before making changes 3eb07708b1 2011-08-04 ben ben-test Merge trunk into ben-testing 75f02948fa 2011-07-22 drh trunk Merge the recent autosetup changes int Andy -- TAI64 timestamp: 40005203eb30 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] simple Fossil For New Users intro guide
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
Re: [fossil-users] cmdline arguments for repopsitory are inconsequent
On 2013-08-08 10:58, Stephan Beal wrote:
On Thu, Aug 8, 2013 at 10:47 AM, Rene renew...@xs4all.nl wrote:
-R seems redundant.
It's not _entirely_ redundant - in some cases it changes how the
arguments are processed. Yes, there are inconsistencies there, but
some of the argument handling relies on one or the other approach.
When the app looks for a CLI flag, e.g. -R, fossil actually removes
that flag and its argument from the global argument list, which
changes the argument count, and many of the commands use logic like
if(g.argc==3){...}, so there non-obvious side effects when changing
whether a command expects -R or not. It the context of libfossil,
that's been one of the minor points on the list of things to consider,
and while i don't much care for inconsistency in software, i _think_
that i'll end up doing it similar to how it is done now. e.g. a clone
implies a -R (but normally in the form of a URL), and doesn't need a
flag. The commands you listed where -R is optional almost always
derive their repo db from the current checkout (which is why -R is not
required). i'm not sure why ui/server don't require -R, but instead
take their repo filename as a non-flag argument. Historical in nature,
i guess.
--
- stephan beal
http://wanderinghorse.net/home/stephan/ [1]
http://gplus.to/sgbeal [2]
Links:
--
[1] http://wanderinghorse.net/home/stephan/
[2] 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
Well lets go the other way a repo, if not in an checkout, must always
be specified with -R.
and maybe if a -R repo is specified in a checkout the -R takes
precedent.
--
Rene
___
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, 08 Aug 2013 22:25:33 +0200, 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 I only had a quick look so this is only a very preliminary feedback: you write: 8--- A smart move might be to designate a directory where you want to store most of your repository files, and initialize new repositories there. These are not the checked out source code files for a project. Unlike most popular DVCSes, Fossil has a separate project database file on any system where you want to have checkouts. This has some advantages (such as making it extremely easy to make backups without having whole checked out source trees, for instance, just by copying the repository database file), though some people might find it strange at first. I typically use ~/frepos (that's a frepos, for fossil repositories, directory inside my home directory) as the location where I store my repository files. Your mileage may vary; this is entirely a personal choice. 8 these remarks: 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. 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). regards, joerg them. -- 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] incomplete documentation?
On Thu, 08 Aug 2013 19:49:18 +0200, Richard Hipp d...@sqlite.org wrote: On Thu, Aug 8, 2013 at 12:40 PM, Julian j...@ptolserv.com wrote: One of the problems is that the help given by fossil help command isn't always complete. For example the help for checkin (fossil help ci), doesn't list the --date-override or --user-override options, even though they appear to be accepted. The same appears to be the case for the branch command. The only way I've found to discover them is to use grep find_option on the source - I'm not sure that is very user-friendly. Two reasons for this. (1) The help text is intended for quick reference and so we don't want to clutter it up with lots of text describing obscure and rarely used options. I would politely disagree: the CL help should be complete, I believe. at least for everything not considered experimental or secret developer features. while git sure is over the top in this regard simply because there are too much options (I had a good laugh once when first looking at `git help log'), a very positive example for me is `hg': it's about as concise as `fossil' but complete as far as I can tell. I know it is work and takes time and the current help is OK but sure its not as complete as it should be in my view. j. (2) Some options we don't want people to use, either because they are dangerous and likely to lead to problems, or because they are experimental and subject to change and perhaps untested, or perhaps the options are deprecated and are still recognized purely for backwards compatibility. The --date-override and --user-override options were put in place to support scripts used to import Fossil content from other repository formats. Both reasons (1) and (2) above apply to these options. -- 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] best practices during a large rewrite
On Thu, Aug 8, 2013 at 9:18 PM, Themba Fletcher themba.fletc...@gmail.comwrote: of the historical features are just going to have to go. cough plaintext passwords in database cough :) FWIW: i learned a great deal about password handling from Fossil when i integrated the JSON API into Fossil's auth system. You might want to take a look there. In short, a user's pw is stored as a hash of a the user's name, password, and possibly the repo's project id. See sha1_shared_secret_sql_function() in src/sha1.c and follow the references to that function. Sounds reasonable, and thanks for your advice. Looks like I'm abandoning trunk and tracking hotfixes by hand as that seems safest. And this makes the separate repo vs separate branch question rather immaterial. That's the way i'd do it, but i really hate being bogged down by compatibility crutches when trying to rewrite something, so i try to distance myself from the original code as much as possible. When porting code over from old to new i'll ever rename functions/classes which don't really need it just so that i can make sure that if i change their semantics, i don't have ported code referencing the old names but expecting different semantics. (i've done a lot of that in libfossil when porting in code from the main repo, when porting bits from app semantics to library semantics.) Good luck with your project! -- - 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 Thu, Aug 8, 2013 at 10:48 PM, j. van den hoff veedeeh...@googlemail.comwrote: 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 In fossil keeping them in the same dir can and does lead to user error. Here's a concrete example which i've done more than once while doing old-school refactoring: perl -i -pe 's|func_name|new_name|g' * fossil commit -m ... fatal: not a checkout ??? Oops - i just filtered through my _FOSSIL_, corrupting it. The same is even easier to do on a repo db because they will match safer wildcards like *.*. (i've done that on SVN repos several times, too, when using find(1) in conjunction with perl.) Yes, silly me - it's my fault, not fossil's. But now that i've done that more than once i know better than to keep my repo and checkout together, and i wholeheartedly convey that advice to you :). i _strongly_ recommend against keeping the repo db in the same dir as a checkout. Very little can go wrong when they're separated and lots can go wrong when they're not. For CGI/server modes, there's a related point: the dir containing the repo must be writable by the CGI/server process, and it's often possible (and always preferable, from a security point of view) to place the db outside of the webroot, in a dir owned by the CGI user (the account holder, for most providers). This keeps the repo from being inadvertently directly downloaded (as opposed to cloned, which has fewer security concerns). -- - 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] cmdline arguments for repopsitory are inconsequent
On Thu, Aug 8, 2013 at 10:29 PM, Rene renew...@xs4all.nl wrote: Well lets go the other way a repo, if not in an checkout, must always be specified with -R. and maybe if a -R repo is specified in a checkout the -R takes precedent. When a checkout is opened, its corresponding repo db is automatically opened as well. Checkout-open fails if the corresponding repo cannot be opened, e.g. it's been moved or deleted. Commands which require a checkout do not explicitly look for -R, but that they instead do this: http://fossil-scm.org/index.html/artifact/770bdc0bc0647650f1c9b59d229964082c4d61f1?ln=1373 Commands which (indirectly) use -R (meaning they do not require a checkout) do this: http://fossil-scm.org/index.html/artifact/770bdc0bc0647650f1c9b59d229964082c4d61f1?ln=866 and that routine then checks for -R before looking for a checkout/repo combination, which, in essence, implements what you suggest: http://fossil-scm.org/index.html/artifact/0adc1aa79c24d8bc88b32e2ef7a8f29d32619d79?ln=1054-1084 FWIW: the the new/prototype libfossil code follows that same heuristic, but that's only a happy accident - it just seemed like the most logical choice. - 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 Thu, 08 Aug 2013 23:12:52 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Aug 8, 2013 at 10:48 PM, j. van den hoff veedeeh...@googlemail.comwrote: 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 In fossil keeping them in the same dir can and does lead to user error. Here's a concrete example which i've done more than once while doing old-school refactoring: perl -i -pe 's|func_name|new_name|g' * fossil commit -m ... fatal: not a checkout ??? Oops - i just filtered through my _FOSSIL_, corrupting it. The same is even easier to do on a repo db because they will match safer wildcards like *.*. yes, that can happen. but nobody prevents the user from messing up the database irrespective of its location I would say. and in-place stream editing of files without taking care (`processing_everyting *' ...) sure is the user's fault in the end. the trivial protection is to use hidden/ dotted files (.fslrepo in my case would be an example). (i've done that on SVN repos several times, too, when using find(1) in conjunction with perl.) but what does this proof? the next guy might be a tidy up fanatic and accidentally remove the directory with all the repository files, right? Yes, silly me - it's my fault, not fossil's. But now that i've done that more than once i know better than to keep my repo and checkout together, and i wholeheartedly convey that advice to you :). that's appreciated but I won't take it (for now, at least ;-)), since I'm quite happy with the state of affairs right now and tend tend to be over-careful when starting stream-editing with wildcard lists. and of course I presume that there _is_ some remote repository which is in sync with my local one so that I'm on the save side anyway (the whole point of using a DVCS, is it?) so overall I am of the opinion to make this a choice of the prospective new user instead of a sacrosanct best practice recommendation. i _strongly_ recommend against keeping the repo db in the same dir as a checkout. Very little can go wrong when they're separated and lots can go wrong when they're not. shall I invent a few things which _can_ go wrong when collecting all repos in a common directory ? ;-) I mean: the mailing lists of git, hg, bzr, svn, ... sure are not that full of posts I messed up my repository, at least not where the 'messed up' is caused by the missing separation of repo and checkout. this (the question where to put the repository file) is another example where I don't quite understand why such a small thing (in my view anyway) causes such strong feelings. I still believe: let the new user decide this himself, but don't strongly recommend one strategy over the other. at least specifically point out where it really can make a difference (multiple checkouts from the same db, maybe?) For CGI/server modes, there's a related point: the dir containing the repo must be writable by the CGI/server process, and it's often possible (and always preferable, from a security point of view) to place the db outside of the webroot, in a dir owned by the CGI user (the account holder, for most providers). This keeps the repo from being inadvertently directly downloaded (as opposed to cloned, which has fewer security concerns). -- 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] simple Fossil For New Users intro guide
i _strongly_ recommend against keeping the repo db in the same dir as a checkout. Very little can go wrong when they're separated and lots can go wrong when they're not. Wholeheartedly concur. In just over two years of daily usage I've lost data exactly once and that was due to having my repo too close to my checkout and there was an unfortunate typo involving the rm command ... Another advantage to a single repos directory is if you run something like the following automatically on startup $ fossil server --localauth -P 8080 /home/tif/Projects/repos you will never have to type 'fossil ui' again. ___ 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 8, 2013 at 11:31 PM, j. van den hoff veedeeh...@googlemail.comwrote: but what does this proof? the next guy might be a tidy up fanatic and accidentally remove the directory with all the repository files, right? My point is only that that type of goof-up happens much more often if the files are in the same place. i can't remember the last time i accidentally deleted/corrupted something which lived in a directory above my current working path, but i can remember a handful of times i've corrupted source repos doing various things i shouldn't have been doing. that's appreciated but I won't take it (for now, at least ;-)), since I'm quite happy with the state of affairs right now and tend tend to be over-careful when starting stream-editing with wildcard lists. and of course I presume that there _is_ some remote repository which is in sync with my local one so that I'm on the save side anyway (the whole point of using a DVCS, is it?) Presumably, but why risk it? It's simply a question of risk management for me. The risk of any loss (maybe just one or two unpushed commits or wiki edits) drops to near 0 if the repo is outside of the source repo. It rises notably above 0 if they live together. so overall I am of the opinion to make this a choice of the prospective new user instead of a sacrosanct best practice recommendation. It's not sacrosanct, but it is best practice. shall I invent a few things which _can_ go wrong when collecting all repos in a common directory ? ;-) i wasn't naming hypotheticals - these are things i've done myself and seen done via posts on this list. I mean: the mailing lists of git, hg, bzr, svn, ... sure are not that full of posts I messed up my repository, at least not where the 'messed up' is caused by the missing separation of repo and checkout. i can mess up git using its own commands - i don't need perl for that ;). -- - 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 Thu, 08 Aug 2013 23:36:14 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Aug 8, 2013 at 11:31 PM, j. van den hoff veedeeh...@googlemail.comwrote: but what does this proof? the next guy might be a tidy up fanatic and accidentally remove the directory with all the repository files, right? My point is only that that type of goof-up happens much more often if the files are in the same place. i can't remember the last time i accidentally deleted/corrupted something which lived in a directory above my current working path, but i can remember a handful of times i've corrupted source repos doing various things i shouldn't have been doing. that's appreciated but I won't take it (for now, at least ;-)), since I'm quite happy with the state of affairs right now and tend tend to be over-careful when starting stream-editing with wildcard lists. and of course I presume that there _is_ some remote repository which is in sync with my local one so that I'm on the save side anyway (the whole point of using a DVCS, is it?) Presumably, but why risk it? It's simply a question of risk management for me. The risk of any loss (maybe just one or two unpushed commits or wiki edits) drops to near 0 if the repo is outside of the source repo. It rises notably above 0 if they live together. so overall I am of the opinion to make this a choice of the prospective new user instead of a sacrosanct best practice recommendation. It's not sacrosanct, but it is best practice. for you - fine. but why for everybody? shall I invent a few things which _can_ go wrong when collecting all repos in a common directory ? ;-) i wasn't naming hypotheticals - these are things i've done myself and seen done via posts on this list. these perceived (or actual) advantages can be stated and again: the (new) user might then decide whether he believes these to be relevant. my point here is: when I started using fossil (coming from `hg') I just presumed the repository needed to reside within the checkout. afterwards I found statements that this might lead to database corruption (caused by fossil not by some stream edit...) then I learned these (old) problems are sorted out. and so I stayed with the initial approach which did me no harm whatsoever so far. your point seems to be that putting the database somewhere else reduces the risk that the user will be messing with it. I cannot (and don't want to) disprove this but it is not relevant for me (I have other ways to mess things up, of course ;-)). so, I maintain, the message should be do as you like, both solutions work just fine, but please be aware of the following pros and cons (and there are some pros for keeping things together, too). I mean: the mailing lists of git, hg, bzr, svn, ... sure are not that full of posts I messed up my repository, at least not where the 'messed up' is caused by the missing separation of repo and checkout. i can mess up git using its own commands - i don't need perl for that ;). very good point! regards, joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
