Re: [fossil-users] clone a repository over ssh where the path includes whitespace characters

[Martin S. Weber]

On 2019-08-08 08:25:30, Andy Bradford wrote:
> Thus said Stephan Beal on Thu, 08 Aug 2019 12:06:30 +0200:
>
> > fossil clone 'ssh://user@domain://path/to/"directory with
> > spaces"/my.fossil' my.fossil
>
> Yes, that  works, but it's  a hack really because  ...

Its behaviour is consistent with other network services whom you give
a single argument with spaces to find on the other host. E.g., scp,
rsync all require the same dance. Insofar it's just consistent, and,
I would argue, meets user expectations/experience.

Regards,
-Martin
___
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] Turning off GCC's "helpful" ansi color escape sequences in error/warning messages

[Martin S. Weber]

On 2018-01-09 19:27:10, The Tick wrote:
> 
> Seems to me that most people will either use script or redirect the make
> output to a file. Computers are simply too fast and the output too
> (...) If you use GCC
> you will probably have noticed that it inserts ansi color escape sequences
> in an attempt to highlight portions of the messages. If you peruse the
> typescript file or log file of your build then these escape sequences are
> very distracting and make it more difficult than necessary to read the
> message. 

GCC is not the only tool with a console UI that does that. In the
"white text on black background" (or vice versa) world, this actually
works somewhat acceptably (minus readability issues). Other color combinations
of terminals - not so much. And you do not know from within the application
what your console's fore- and background colors are (you may possibly sometimes,
but usually you don't). 

So please, if you're a SW dev who is reading this and thinking about
adding color output to your tool of choice, think how it'll look on 
white-on-red, yellow-on-green, black-on-darkgoldenrod, ... , wisen up, 
don't add it or do, please, add an option to turn it off.

Thanks.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Martin S. Weber]

On 03/27/17 01:55, Roy Marples wrote:
Pager output disappearing with the pager (I assume when asking the 
pager to exit) is an issue with the pager.


I disagree. Disappearing output uses the "alternate screen" of a 
terminal so that the pager's output does not interfere with your 
non-reading session. It most certainly is a feature, and one with a long 
history to lean on as well.


Regards,
-Martin
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Martin S. Weber]

On 2017-03-26 15:13:53, Christophe Gouiran wrote:
> I come back to you with an implemented solution.
> 

Your solution doesn't check whether stdout is actually pointing to a terminal.
You should never invoke a pager if it's not.

I also think this is a horrible idea in general.

Regards,
-Martin
___
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] Support for commonmark markdown in fossil

[Martin S. Weber]

On 03/13/17 19:00, Warren Young wrote:

On Mar 13, 2017, at 10:32 AM, Natacha Porté  wrote:

Or do you expect it to count parentheses and prevent you from ever
linking to a URL with unbalanced parentheses?


Yes.  Other Markdown processors do that.


It doesn't necessarily have to count parens, in the specific case 
mentioned by Warren opting for the longest instead of the shortest 
syntactically correct match would do as well. In other words, use

regexen naively, duh :)
___
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] Bug in "fossil branch new"

[Martin S. Weber]

On 2017-02-07 07:59:03, Andy Bradford wrote:
> Thus said "Martin S. Weber" on Tue, 07 Feb 2017 11:07:55 +0100:
> 
> > thanks for proving my point.
> 
> You're welcome. I  never said branch names don't identify  a branch, nor
> that they  are meaningless.  

drh said branch names don't identify a branch, not you. If names did identify
branches, there would be no way to have two separate branches of the same 
name, as the name would uniquely identify a branch. It doesn't, though.

> I said  that when  you use  ``fossil branch
> new'' that  it doesn't imply that  the following commit will  be on that
> branch.

a fossil update following the branch new would be more user-friendly indeed,
at least IMHO.

My point is, what is the rationale for names not identifying branches
uniquely. Why can I multiple branches off of several basis that have the
same name? See my previous email with the fossil command log output how
even fossil assumes the samely named branches are the same (by outputting
one leaf as "current" and not the other, whereas, if these are indeed
separate branches, both leaves of the same-named branch name need to
be "current").

> 
> And given the following:
> 
> > This could  be mitigated,  by keeping  the same  design, with  the CLI
> > actually outputting  an identity  of the  branch that  can be  used to
> > select that specific branch.  If the name is but a  tag, do output the
> > actual identity.  Problem then becomes one  of the user-unfriendliness
> > of entering hashes for symbolic names (why have symbolic names if they
> > are worthless?).
> 
> Does not  Fossil allow  the use  of names for  most operations  and will
> attempt to  resolve them  in a deterministic  fashion? Who  claimed that
> they are worthless?

Well, worthless in its ultimate ratio in its current state (aka playing
devil's advocate). Deterministically picking the wrong thing doesn't 
help. See the email with the fossil output. If I can only pick the "other"
dev branch by its hash, then the name of that "other" dev branch has become
worthless, as it will not resolve to the older one.

Regards,
-Martin
___
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] Bug in "fossil branch new"

[Martin S. Weber]

On 2017-02-06 23:17:00, Andy Bradford wrote:
> (...)
> Because it doesn't  matter what the name  of the branch is.  
> (continues to show examples where Andy, as the human, uses the branch-name to
> identify the branch)

thanks for proving my point.

Regards,
-Martin
___
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] Bug in "fossil branch new"

[Martin S. Weber]

On 2017-02-06 11:13:46, Richard Hipp wrote:
> (...)
> Probably you are coming from a different DVCS that requires branches
> to be created in advance of the commit and that also requires branch
> names to be unique.  Fossil has neither of these constraints, and so
> it operates a little differently from what you might be used to.

Well, given fossil's CLI requires BRANCH-NAME as input, how can
the following commit not go to the same branch? To me, this is a bug
in fossil as well, and confusing behaviour on top of it. I've learned
a while ago to not create a branch before usage because it's confusing
to the user, and that is a bad thing (tm).

If multiple branches of the same name exist, the fossil CLI does
not qualify for adressing these. That's a bad thing (tm).

Branches do not have an identity. The name is useless to fossil and
user. IMHO it's time to stop defending this design principle and select
a better design principle that stops confusing users and allows them
to actually identify and address a branch using fossil's native CLI.

Imagine you have two same-named branches in different parts of your
version graph, when you select one of these, how would you know which
of these you selected? You can't, except by inspection of the content.

This could be mitigated, by keeping the same design, with the CLI actually
outputting an identity of the branch that can be used to select that specific
branch. If the name is but a tag, do output the actual identity. Problem
then becomes one of the user-unfriendliness of entering hashes for symbolic
names (why have symbolic names if they are worthless?). Again, IMHO, this needs
to be revisited to be human-friendly. @drh: how would you, from the output of
fossil branch ls, select the branch head that equates to version e943565869 ?

fossil update dev will warn about the multiple leaves, and wrongly claim that
one of these two is "current". Actually both are "current" when you assume
that the name does not identify a branch, because these two are completely
separate identities. So the CLI actually is inconsistent with the design of
fossil.

If you continue the line of thought that branch names are not to be unique,
one could as well create a fresh branch for each checkin. So, say, there's
five commits on trunk, that would be five different-but-samely-named "trunk"
branches in the repo. Madness!

Regards,
-Martin


$ fossil new yo.fossil
project-id: 8144232186a07805496c756830b99307000df301
server-id:  b837d648f0424d4b9c98667e195bc56674c76774
admin-user: phaeton (initial password is "f51de9")
$ mkdir yo
$ cd yo
/home/phaeton/tmp/bla/yo
$ fossil open ../yo.fossil  

project-name: 
repository:   /usr/home/phaeton/tmp/bla/yo/../yo.fossil
local-root:   /usr/home/phaeton/tmp/bla/yo/
config-db:/home/phaeton/.fossil
project-code: 8144232186a07805496c756830b99307000df301
checkout: d2efb912b99c568ad0cee694c5ce9f50396c60f6 2017-02-06 16:58:31 UTC
tags: trunk
comment:  initial empty check-in (user: phaeton)
check-ins:1
$ touch a   

$ fossil add a
ADDED  a
$ fossil ci -m 'a.' a
New_Version: 6025c147db18aaf23820068b4fb05635d2729de6
$ echo yo >> a  

$ fossil ci -m 'a.dev' --branch dev a
New_Version: e943565869bf485986a8d588219399a60a9105ed
$ fossil timeline
=== 2017-02-06 ===
17:00:05 [e943565869] *CURRENT* a.dev (user: phaeton tags: dev)
16:58:55 [6025c147db] a. (user: phaeton tags: trunk)
16:58:31 [d2efb912b9] initial empty check-in (user: phaeton tags: trunk)
+++ no more data (3) +++
$ fossil update trunk
UPDATE a
---
updated-to:   6025c147db18aaf23820068b4fb05635d2729de6 2017-02-06 16:58:55 UTC
tags: trunk
comment:  a. (user: phaeton)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
$ echo oy >> a  

$ fossil ci -m 'oy!' a
New_Version: 1ff2fa69b5a21571dbb3b60b63c5155686f10107
$ echo dev >> a 

$ fossil ci -m 'oy.dev' --branch dev a
New_Version: 41b2cea47b0f23c6339222583f6cc9d07660ac8d
$ fossil timeline
 === 2017-02-06 ===
 17:01:56 [41b2cea47b] *CURRENT* oy.dev (user: phaeton tags: dev)
 17:01:32 [1ff2fa69b5] oy! (user: phaeton tags: trunk)
 17:00:05 [e943565869] a.dev (user: phaeton tags: dev)
 16:58:55 [6025c147db] *BRANCH* a. (user: phaeton tags: trunk)
 16:58:31 [d2efb912b9] initial empty check-in (user: phaeton tags: trunk)
 +++ no more data (5) +++
$ fossil branch ls 
 * dev
   trunk
$ fossil update dev
---
checkout: 

Re: [fossil-users] Git just got shallow and sparse clones

[Martin S. Weber]

On 2017-02-04 15:01:43, Jan Danielsson wrote:
> (...)
>So when you do your initial clone, it only downloads some metadata
> about what files exist in the repository, but not the contents of them.
> When you open a file, the vfs will fetch the file for you.
> 
>Say a project has a doc/ directory which is unrelated to the build
> process, and there are 200MB worth of documents in there.  A person who
> just wants to build the project probably doesn't want to download all
> those docs, so they just kick off the build without touching the files
> in doc/.
> 
>Like I said, I only skimmed a few seconds so I could be way off, but
> that's what it looked like to me.
> 
>If it is what I think it is:  With all these indexing tools out
> there, scanning every file it finds, I wonder how useful this feature
> really is?

It's clearcase all over again. I don't remember the specifics (it's
nearly 20 years ago I was working on a clearcase VFS checkout under
solaris), but we (clearcase users) preferred the explicit nature
of CVS back then. IIRC, shared access to the VFS was leading to all
sorts of kinky side-effects.

Personally, I'd neither use a git, nor a fossil virtual file system,
much less when it requires an up to date Windows 10 installation
and a MS git binary.

Regards,
-Martin
___
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] Adding binary files to fossil

[Martin S. Weber]

On 2017-01-03 10:08:40, Scott Doctor wrote:
> What is the proper way to add binary files to a repository?

Follow the following steps:

(1) (fossil) add the files.
(2) you're done. 
(3) No, really, you're done.
(4) Enjoy.

fossil will warn you that these files look binary. Read the warning
and answer accordingly.

With fossil settings you can specify the binary-glob which will allow
you to circumvent the warning.

With versioned settings (create a .fossil-settings directory in your
top-level checkout directory and create a, say, binary-glob file in
it which contains a comma-or-newline separated list of glob patterns
describing your binaries) you can make sure this setting propagates
properly to other clones.

cf. (4) above
___
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 & cgi bleed (Proxy / HTTP_PROXY)

[Martin S. Weber]

On 2016-07-18 18:07:22, Richard Hipp wrote:
> On 7/18/16, Martin S. Weber <ephae...@gmx.net> wrote:
> >
> > But it uses the http_proxy environment variable, doesn't it,
> > which a front-end web server might (or, will, according to RFC 3875,)
> > set before invoking fossil as a cgi.
> 
> Only shell commands (ex: "fossil sync") use the HTTP_PROXY environment
> variable, and those are not accessible via CGI.

So no auto-sync setting, no TH1 code hooks, ...

That sounds like good enough.

Thanks for the analysis,
-Martin
___
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 & cgi bleed (Proxy / HTTP_PROXY)

[Martin S. Weber]

On 2016-07-18 17:27:52, Richard Hipp wrote:
> On 7/18/16, Martin S. Weber <ephae...@gmx.net> wrote:
> > More info e.g. at https://httpoxy.org/
> >
> > suggested fix: "If you’re running PHP or CGI, you should block the Proxy
> > header now."
> >
> > Fossil's suggesting deployment as a CGI
> > Fossil's using http_proxy itself (as client)
> >
> > wondering whether:
> > - fossil can be convinced to be exploitable by a well crafted proxy header
> > - std CGI setup instructions should include deleting the Proxy header
> 
> The CGI logic in Fossil already ignores the "Proxy:" header.  So I
> don't see how this can be exploited.

But it uses the http_proxy environment variable, doesn't it, 
which a front-end web server might (or, will, according to RFC 3875,)
set before invoking fossil as a cgi.

so the Proxy: header should be scrubbed in the front end server, not
fossil itself, so that fossil-as-cgi can trust the setting of HTTP_PROXY.

..is what I take away from it.

Regards,
-Martin
___
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 & cgi bleed (Proxy / HTTP_PROXY)

[Martin S. Weber]

More info e.g. at https://httpoxy.org/

suggested fix: "If you’re running PHP or CGI, you should block the Proxy header 
now."

Fossil's suggesting deployment as a CGI
Fossil's using http_proxy itself (as client)

wondering whether:
- fossil can be convinced to be exploitable by a well crafted proxy header
- std CGI setup instructions should include deleting the Proxy header

Regards,
-Martin
___
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] Skin almost finished.

[Martin S. Weber]

On 2015-05-01 11:58:30, John Found wrote:
 (...)
 Well, maybe it is a bad practice, but my browser is always maximized.
 Also, all people I know maximize their browsers...

Which is why I was saying, one keystroke and you're ready for
prose-reading-mode, but the other way around, there's no way for you to
reach that. If your windowing environment STILL doesn't support at least
basic tiling, it's time to change ;)

Regards,
-Martin
___
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] Select specific changes within files

[Martin S. Weber]

On 2015-03-20 13:04:44, Richard Hipp wrote:
 (...)
 The way I deal with this in SQLite is:
 
 (1) Make logically separate changes in separate check-outs so that
 they are easy to test and commit separately.  (...)

That's the sort of flow-interrupting context switch I was referring to
on one hand, for myself; I see the usefulness of this approach, also it's
very KISS. I like it. I usually do not treat checkouts as transient as
this implies, but there's nothing wrong with doing that, considered it
does not interrupt you. Maybe having it in mind won't interrupt me next
time I stumble over it, I'll wait and see.

 (2) On the occasions when I mess up and accidentally put (...)

That's the sort of thing that one can do after the fact, i.e., when
the housekeeping portion after the productivity burst is coming to
take a breather... see more below.

 (3) You might also check-in the whole thing into a side branch, then
 do multiple partial merges back into the branch you were (...)

I can see one doing this when they approach their checkout with a
plan they know will create mess. It's good advice.

I think in combination, your three approaches actually cover the use-cases
I have, when I'm considering the topic of partial commits.  I suppose the
process of (2) and a partial commit selection would be actually end up
being quite similar (in (2) you have more (visual) context but you make 
the same choices for the most part, i.e., select this, ignore that, ...)

Partial commits would offer a line of defense, of cleaning up and 
associating metadata with changes. (2) fulfills this role just as well.
(1) is good reminder/advice for when the opening is quick. People
should be doing (3) for messy stuff anyways :)

 Still, there will always be people who are convinced that there is
 nothing that can go wrong and what to do a partial commit against
 expert advise.  

I wanted to showcase the potential usefulness of the feature. You're
saying you got me covered already. After some consideration I think
I agree. So no need for me to ask for and rely on yet-unwritten code.

Thanks,

-Martin
___
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] Select specific changes within files

[Martin S. Weber]

On 2015-03-20 09:02:32, Richard Hipp wrote:
 (...)
 I'm still having trouble understanding how the partial commit would be
 *useful*, though.

Some people like their metadata (i.e. fossil's commit message log) to
match up with what they were doing in the files. You go to your file, you
begin to work on task A, something comes along, and work on task B gets
intermingled with the A changes. You wanna commit with metadata (commit
log) that clearly says A was done here, and B was done there. Often
enough, it's easy to halt before starting on B, commit (or stash),
go on to B, etc.

Also, ideally you're working in a flow anyways (the deep meditative
state where stuff gets done (tm)); doing housekeeping (stashing here
and there; grouping related changes to single commits so that you can
cleanly test them / undo them as a human without the need for tools such
as unit-testing combined with fossil bisect) is a safe way to kill any
meditative effort (except for real housekeeping, obviously meditative
in itself). So you end up with intermingled changes which one would
like to split cleanly.

But fossil is not git, you can't tear your history apart.So you have to
make sure the right history gets recorded (forever) in the first place. 
And we're back at partial committing with usefulness.

Regards,
-Martin
___
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] possible error

[Martin S. Weber]

On 2015-03-17 17:06:33, Ramon Ribó wrote:
 fossil version
 This is fossil version 1.32 [302052d30b] 2015-02-20 08:30:51 UTC
 
 fossil sync
 Usage: c:\other\binutils\fossil.exe sync URL
 
 is it not possible to use sync without URL?

It is, after you've stored your sync settings (i.e. who is to be your peer)
in your local settings. You can see this url by issuing the fossil remote-url
command, and can set it there, too, see fossil help remote-url.
Sample would be fossil remote-url http://u...@ho.st:port/path/to/repo

Have fun,
-Martin
___
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 graph display options

[Martin S. Weber]

On 2015-03-09 21:42:51, Andy Bradford wrote:
 Thus said Richard Hipp on Mon, 09 Mar 2015 23:06:59 -0400:
 
  Which timeline graph do you prefer:
  
  (1) https://www.fossil-scm.org/fossil/timeline?y=cinomo=0
  (2) https://www.fossil-scm.org/fossil/timeline?y=cinomo=1
 
 (1) because the relationship to the node from which the arrow originates
 is more clear to me.
 

Same thought here.


___
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] Horror story about git - Forever Alone

[Martin S. Weber]

On 2014-09-25 08:44:04, Gour wrote:
 Morning,
 
 just read it today on Reddit:
 
 http://www.reddit.com/r/programming/comments/2hctgh/horror_story_about_git_forever_alone/
 
 Article is at: http://thedailywtf.com/Articles/Forever-Alone.aspx
 
 What about Fossil in the same scenario?
 
 

What's supposed to happen? The same thing. If you keep committing a binary
file, changing it completely between each checkin, the repo's gonna become a fat
thing. As you asked for it.

This is in no way IMHO a GIT horror story. It's just a mild case of 
PEBKAC (who ended up quitting anyways), i.e., HR fckup.

Regards,
-Martin
___
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] Please improve documentation for the checkout command

[Martin S. Weber]

On 2014-03-20 12:46:15, Stephan Beal wrote:
 (...)
 # f help
 Usage: f help COMMAND
 Common COMMANDs:  (use f help -a|--all for a complete list)
 add changes gdiff   openrss ui
 addremove   clean   helppraise  settingsundo
 all clone   import  pullsqlite3 update
 annotatecommit  infopushstash   version
 bisect  diffinitrebuild status
 blame   export  ls  remote-url  sync
 branch  extras  merge   revert  tag
 cat finfo   mv  rm  timeline
 
 Weird. i'll fix that tonight unless one of the other devs says there was a
 reason why co/checkout was left out of that list. (In practice, though,
 checkout generally tends to only be used only once for a given local repo
 copy.)

...which is, AFAIUI, the reason why it's not on the short list of help topics.

Actually, in my mind, when reading Michael's message, I kept thinking: uhm,
you got it open, now update ;)
(not disputing the need for documentation; this is a report from experience
 of what went wrong and this should be fixed)

Regards,
-Martin
___
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] Please improve documentation for the checkout command

[Martin S. Weber]

On 2014-03-20 12:47:35, David Mason wrote:
 Are branches easier to deal with in fossil?

Using hg at work, I completely understand why one would stay away from
branches. Using fossil at home, I completely fail to understand why one
would work on trunk. 

Can't really tell you much about the why except: why do you have drawers
instead of a huge chest? What I usually do is for each experimentation,
I use a branch, and each feature starts as an experiment anyways. So
they get born on a branch. Usually a development of related modifications
that will need some iterations sits on a branch for me until it's feature
complete. Trunk then sees one change bringing in the feature I was working
on. Depending on future work, the branch gets closed afterwards (or not, to
be revisited with further related work).

Regards,
-Martin
___
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] Version 1.28 release?

[Martin S. Weber]

On Thu, Jan 09, 2014 at 11:19:45AM -0500, Richard Hipp wrote:
 On Thu, Jan 9, 2014 at 11:12 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
 
  2014/1/9 Richard Hipp d...@sqlite.org:
   Jan - would you like to start the branch-1.28 containing the SQLite
  3.8.2
   release?
 
  http://fossil-scm.org/index.html/timeline?r=branch-1.28
 
 
 Jan: tnx
 
 Everybody:  Please download, compile, and test the branch above.  If there
 are no issues reported, it will become the official 1.28 release.
 

* Final result: 27 errors out of 18957 tests
* Failures: merge-utf-24-23 merge-utf-24-32 merge5-10 merge5-50 merge5-72 
merge5-90 merge5-91 merge5-100 merge5-101 merge5-102 merge5-110 merge5-120 
merge5-121 merge5-122 merge5-123 merge5-130 merge5-131 merge5-132 merge5-133 
merge5-134 merge5-135 merge5-136 merge5-140 merge5-141 merge5-142 th1-setting-5 
th1-setting-6

on Linux 3.12.6-1-ARCH x86_64
with gcc version 4.8.2 20131219
from fossil 1f10199a09724a50 (1.28 branch tip)

Side note: failing tests do not print info on stderr (it all goes to stdout 
from a 'make test' invocation POV)
Being able to run make test  /dev/null 2 errs  rm -f errs || ${PAGER:-more} 
errs would be nice ;)

-M
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

[Martin S. Weber]

more info: test-out @ http://phaeton.sdf-eu.org/fossil-1f10199a09724a50-test-out

-M
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

[Martin S. Weber]

On Thu, Jan 09, 2014 at 09:31:59AM -0500, Richard Hipp wrote:
 On Thu, Jan 9, 2014 at 9:17 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
 
 
  The latter has the advantage that no new Fossil binary
  has to be built when SQLite 3.8.3 is released. Fossil will
  always follow the latest stable SQLite automatically.
 
 
 But I want Fossil to follow the latest SQLite alphas, not the latest SQLite
 stables.  That's the whole point:  Fossil supports SQLite as a test
 platform.  SQLite stable has already been thoroughly vetted and tested and
 there is little point in testing it further.  I want Fossil to run with the
 latest SQLite on trunk to smoke out bugs early.

...but fossil in itself is a pretty awesome piece of software, that's expected
by its users to be stable -- at least for releases.

Regards,
-Martin
___
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] survey: your top 5 most-used fossil CLI commands?

[Martin S. Weber]

On Mon, Sep 02, 2013 at 06:36:42PM +0200, Stephan Beal wrote:
 (...) So... which fossil CLI commands do you use most often, NOT counting the
 following (which are more or less required for any real work): (...)

changes
add/addremove/rm/mv
stash
merge
(settings? remote-url?)

would be what completes my workflow pretty much (leaving ui/server off).

Regards,
-M
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?

[Martin S. Weber]

On Mon, Sep 02, 2013 at 07:30:01PM +0200, Stephan Beal wrote:
 @All:
 Your answers surprise me a bit, guys. addremove, really? i've never used
 that one, either.

I find it easy to bring my checkout to the state I want the DB to reflect
and then just go ahead and do so in a single swoop. Getting (all) files 
in place and teaching fossil about it is one of my use cases, if you will.

Regards,
-Martin
___
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] survey: your top 5 most-used fossil CLI commands?

[Martin S. Weber]

On Mon, Sep 02, 2013 at 07:54:35PM +0200, Stephan Beal wrote:
 On Mon, Sep 2, 2013 at 8:41 PM, Martin S. Weber ephae...@gmx.net wrote:
 
  I find it easy to bring my checkout to the state I want the DB to reflect
  and then just go ahead and do so in a single swoop. Getting (all) files
  in place and teaching fossil about it is one of my use cases, if you
  will.
 
 
 i can see that being useful for an initial setup, but how often do you set
 up new repos? Surely you do other things more often than addremove?

For me, new functionality often includes adding one or two source files,
a test file, mock data, templates and other data that is being used by
the functionality, etc. I blitz in a couple new files every now and then,
or get rid of a bunch, and then sync fossil with my checkout. Of course
I'm not doing it that often, one of my current projects, a month's worth
of development, has seen about a dozen instances of addremove after the
initial setup.

 What i tend to do with a new tree is kind of sloppy:
 
 f add .
 fst
 
 and then go 'f rm' any which i don't want.

I tend not to have files in my checkout that don't belong into
fossil. If files are not there, and fossil thinks they are, they
need deleting from fossil very often. Usually comes in conjunction
to adding a bunch of other files :)

Anyways, that's how I use it.

Regards,
-Martin
___
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] sqlite errors after reinstalling fossil

[Martin S. Weber]

On 01/17/13 16:46, Joseph Mingrone wrote:

One change I made when I upgraded the box was that I set home
directories to be nfs mounted from a storage server.  I'm using the
automount daemon to do the mounting.  Before home directories were
local.  To test if this was causing a problem I created a new user
with a local home directory.  This new user can run fossil without
problems.  The root user also has a local home directory.


Wild guess: are you running your rpc services, lockd and statd amongst them? 
(server? client?)


I'd expect sqlite to trip over not being able to (f)lock a file...

-Martin

___
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] anything speaking against fossil add --commit ?

[Martin S. Weber]

On 07/10/12 10:30, Benoit Mortgat wrote:

What do you want the command to do in this case:

  * edit foo.txt (versioned)
  * fossil add --commit bar.txt

Do you want the commit to just add bar.txt to the version control, or
to also include foo.txt changes?



Given that fossil add is a no-op when a file is versioned already, it would be 
natural to just do what has been asked: add and commit, i.e., no-op and 
commit.


Regards,
-Martin
___
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] anything speaking against fossil add --commit ?

[Martin S. Weber]

On 07/10/12 12:13, Richard Hipp wrote:


Why do you think you will be more likely to type --commit after fossil add than you 
would be to type ; fossil commit?



Well, assuming there's a shorthand for the option, I find it more natural to 
add these extra three characters on the 'add' line than going

CTRL+P CTRL+A ALT+f ALT+f CTRL+w ci (or ^add^ci).

Usually I don't want to commit freshly added files and changed, versioned 
files in one go. Often enough though,  I do have additions and commits at the 
same time :) In the seldom cases where I'm just adding something, I'm usually 
lazy and go addremove;ci which is short enough because there's no list of 
filenames involved.


I'd of suggested add commits automatically (or setting-based), but figured
I wouldn't get very far with that..

So in the end, say, fossil add -c, is just a (personally perceived) usability
improvement on the CLI.

Regards,
-Martin
___
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] Prototype JSON wiki editor demo online

[Martin S. Weber]

On 09/22/11 18:14, Baptiste Daroussin wrote:

So there's the markdown support some of you have been asking for. :)


Sorry for stupid question but does that mean that you bundled a
markdown library? if yes which one?

Or how do you render the markdown?


You should have quoted one more sentence of context:

On 09/22/11 16:31, Stephan Beal wrote:
 (...) In such a case, the
 wiki could hold any text content type you care to use, and use
 client-side rendering.

 So there's the markdown support some of you have been asking for. :)

The critical info is ...and use client-side rendering.

So the infrastructure is there now. All you need is to find and get a 
client-side markdown (or whichever wiki dialect you prefer) library and throw 
it at the content you're getting back from the json interface.


HTH,
-Martin
___
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] any interest in integrating jimtcl w/fossil?

[Martin S. Weber]

On 09/21/11 14:12, Ingo Koch wrote:

On 09/20/11 15:53, Martin S. Weber wrote:

On 09/20/11 19:20, Steve Bennett wrote:

It is the interface to fossil which is important.


Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll
have time for that (at least rounding up an API suggestion) next week.


Please keep in mind that such an API should not only help implementing language
bindings for fossil but should also support tool makers.


Absolutely. Rest assured, I do:

On 09/20/11 15:00, Martin S. Weber wrote:
 Of course if you're an IDE person, you'll
 appreciate easier integration with, say, the behemothian eclipse, the
 leviathan netbeans, the Zizian IDEA or the all-encompassing emacs.

Sorry I forgot to mention the humongous VisualXXX ;)

Regards,

-Martin
___
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] any interest in integrating jimtcl w/ fossil?

[Martin S. Weber]

On 09/20/11 11:19, Stephan Beal wrote:

Hi, all,

i'm just curious - is there any interest out there in integrating jimtcl
with fossil, e.g. as a replacement for th1? While i'm not currently a
tcl user, binding C/C++ code to scripting languages is a hobby of mine
(e.g. http://code.google.com/p/v8-juice), and i'd be interested in
assisting with such an effort, but until the JSON API is done i couldn't
take it on myself. If we had the full power of tcl, as opposed to the
minimalistic th1, we could almost certainly do some really cool things
with it, e.g. adding new features completely in tcl.


Yes. It is one of my plans, the reasons I joined here, to extend fossil with 
tcl. Whether that's ought to be jimtcl (for size and embedding concerncs) or 
the real full-blown tcl (for compatibility with the language and all the 
software out there), I haven't come to a decision yet. Of course the 
single-file approach of fossil has to be kept up. So if you want to include a 
standard library, starpacks etc. come into play..


Anyways, I'm still sketching and juggling available time with other projects 
:) But definitely, I want to see a real language in fossil, and fossil being a 
library for that language...


-Martin
___
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] any interest in integrating jimtcl w/ fossil?

[Martin S. Weber]

On 09/20/11 11:52, Stephan Beal wrote:

On Tue, Sep 20, 2011 at 5:44 PM, Martin S. Weber martin.we...@nist.gov
mailto:martin.we...@nist.gov wrote:

Yes. It is one of my plans, the reasons I joined here, to extend
fossil with tcl. Whether that's ought to be jimtcl (for size and
embedding concerncs) or the


i only suggest jim because it's already in the source tree (and it
appears to be quite powerful, with lots of optional modules). And jimtcl
is a one-file distribution, so physically the integration is trivial.


I know and like jim. I was around on the tclers chat when it was conceived :) 
There's one thing that I don't like about it now though, there's no clear 
compatibility statement wrt tcl itself, or at least none I could find. I'd 
like a table of all the tcl commands and their subcommands and a 
check-or-cross for their support in jimtcl... Without that, it's hard to 
decide which to take. Naturally, Tcl in itself is highly portable, and a good 
enough wrapper around exec (via the file command) to support wrappers/triggers 
portably. It's gonna be fun to hack this up.


On a side note, fossil should grow something to import artifacts-with-history 
from other projects/databases. Tcl itself is managed via fossil. If fossil 
could import properly, 3rd party software use could be handled way better imho...


-Martin
___
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] any interest in integrating jimtcl w/ fossil?

[Martin S. Weber]

On 09/20/11 12:07, Konstantin Khomoutov wrote:

Not that I ever had any need to touch either th1 or jimtcl, but I'd
like to ask an obligatory question: what are the current th1's
shortcomings so that replacing it with something else is needed?


It's no general programming language. It is modeled after Tcl, but implements 
only a very tiny subset of the language. What Th1 is doing can be done as well 
by a full-blown programming language. Having one of the latter integrated with 
fossil would also mean that you can call fossil from the language (and not 
only the other way around). Which would enable you to integrate fossil into 
more software written in that language. Choosing a portable language like Tcl, 
which supports portable path names, program execution etc., has the benefit 
that then you can implement hooks/triggers as calls to tcl procedures, which 
then may (portably) call external programs if they so wish, or use existing, 
stable and featureful libraries for performing the checks/actions they wish to 
perform.


-Martin
___
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] any interest in integrating jimtcl w/ fossil?

[Martin S. Weber]

On 09/20/11 12:49, Konstantin Khomoutov wrote:

Well, my question was actually a veiled uneasy feeling about
possible code bloat and feature creep.



If you look at the top feature request for fossil I wouldn't say that's bloat 
or feature creep. It's a necessity for fossil to be considered in some settings.



While I *am* a Tcl aficionado, for me, one of the Fossil's selling
points is its self-containment and a minimal set of dependencies.


As I've written in another email, the single-file blessing of fossil needs to 
be contained. Anything not fulfilling that is a failure even before its 
conception. Static linking of the respective language library is a must, as is 
self-containment of its (standard) library. Users may choose to use the system 
installations for both, naturally, as is possible already right now for using 
the system sqlite. But I do not want, at all, to touch the single file 
blessing of fossil.


Regards,
-Martin
___
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] any interest in integrating jimtcl w/ fossil?

[Martin S. Weber]

On 09/20/11 12:55, Andreas Kupries wrote:

On 9/20/2011 9:01 AM, Martin S. Weber wrote:

On a side note, fossil should grow something to import artifacts-with-history
from other projects/databases.


How would the proposed command (extension) differ from the existing

fossil import --incremental --git REPOSITORY  GIT-FAST-EXPORT-FILE


You're saying to import another fossil project A into my project B, I should 
export that other project into A.git and then import the resulting project 
A.git into B.fossil?


-Martin
___
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] any interest in integrating jimtcl w/ fossil?

[Martin S. Weber]

On 09/20/11 12:58, Joe Mistachkin wrote:

Has you looked at the tcl-integration branch in Fossil?  It has
experimental
changes to allow full-blown Tcl to be used in Fossil.  It allows Tcl and
TH1
to call into each other.


I've seen it, but I disagree with the approach. Tcl is a superset of Th1. Th1 
should disappear within tcl, if tcl is present, IMO.


-Martin
___
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] any interest in integrating jimtcl w/ fossil?

[Martin S. Weber]

On 09/20/11 13:00, Stephan Beal wrote:

On Tue, Sep 20, 2011 at 6:49 PM, Konstantin Khomoutov
flatw...@users.sourceforge.net mailto:flatw...@users.sourceforge.net
wrote:
While I *am* a Tcl aficionado, for me, one of the Fossil's selling
points is its self-containment and a minimal set of dependencies.


That's the beauty of jimtcl - it's already there and required (or
optionally used) by the build process, so deps aren't a problem here.


Dependencies on the source level never are a concern (if the license is right) 
because we can import anything into some subdirectory of fossil's fossil. It's 
run-time dependencies that count. Yes, jim fares well there, too, but I have 
other concerns with it...


-Martin
___
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] any interest in integrating jimtcl w/fossil?

[Martin S. Weber]

On 09/20/11 13:38, Steve Havelka wrote:

Excuse my bluntness:  that sounds like a terrible idea.  Tcl is huge
compared to fossil, and certainly not installed everywhere by default.


Which is why it would have to be integrated in the fossil source, built from 
source, and attached to fossil at buildtime. No runtime dependencies. 
Alternatively, if jimtcl was the way to go, we're talking about a 200k 
increase in the fossil binary, no external dependencies at all. Does that 
sound so bad?



And for what benefit?  To have a full-blown programming language built
in?


It's the other way around. Proper tcl integration would also mean to turn 
fossil around, so that fossil is actually the library, allowing to call any 
fossil command (and, in some cases, even finer-grained controls) from within 
that other PL.


 That of course isn't a benefit in itself.  If an organization needs

some sort of sophisticated processing attached to a hook, e.g. some
verification on commits, let them call an external program, a shell
script, a tcl script, whatever.


It can't do so portably. To do that, it would have to introduce a compat layer 
handling the platform differences of windows/unix/... Then again, it could use 
an existing compat layer. Like Tcl.


 Embedding an interpreter into Fossil

itself, to run code called by the hook, seems like entirely the wrong
approach.


Again, the right way to integrate those two would be to make fossil a library. 
If done properly, bindings for other languages can emerge naturally. And of 
course there needs to be a compile-time option to strip all that support in 
case you want a real slim fossil binary. As Stephan said in another context, 
it's a herculian task. But one worth undertaking IMO.


Regards,
-Martin
___
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] any interest in integrating jimtcl w/fossil?

[Martin S. Weber]

On 09/20/11 14:53, Eric wrote:

I agree entirely. I think Fossil is in danger of becoming some sort of
Swiss Army Knife, rather than a finely honed specialised tool.


Actually fossil IS a swiss army knife. It combines a DVCS with tickets, wiki, 
http UI, user-mgmt  embedded doc. Its specialization is its swiss army knife 
function, while remaining self-sufficient.


 The only

suggestion for major change that I have seen lately that I approve of is
to be able to build Fossil as a library.


If you have fossil as a library, having something to remote-control the fossil 
library is the next logical step. Of course if you're an IDE person, you'll 
appreciate easier integration with, say, the behemothian eclipse, the 
leviathan netbeans, the Zizian IDEA or the all-encompassing emacs. In case you 
aren't and want a finer grained control and scriptability than is doable right 
now with shell scripts and parsing the output of fossil, then I think you'll 
appreciate integration with a (script) language. One point of the whole 
integration is, as has been stated already, for it to be optional (not the 
fossil as library part, but the remote control part). No harm done for you if 
you don't want to use it; just as there's no harm done if you don't want to 
use the wiki, tickets, the user management, the web UI, i.e., fossil as a 
swiss army knife.


Regards,
-Martin
___
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] JSON/wiki: what info needs to be returned for...

[Martin S. Weber]

On 09/17/11 08:35, Richard Hipp wrote:

(Aside:  Should we create a new fossil-dev mailing list for this kind of
thing, and preserve fossil-user for use by people who just want to use
Fossil and don't really care what is happening behind the scenes?)


Yes please :)

-Martin
___
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 code style question...

[Martin S. Weber]

On 09/16/11 14:26, Stephan Beal wrote:

To be clear: i'm not going to argue either way, i just want to conform.


Which reminds me, try building your code with either c89 as compiler or pass 
-ansi to gcc. There's still a fix necessary for fossil's sha1 computation (see 
previous thread starting at 
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg05772.html )


-Martin
___
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: numerous open trunk leaves

[Martin S. Weber]

Hey fellow archaeologists,

I was just wondering: how did fossil end up with all these distinct open 
leaves of the same branch? If you look at our leaves display here:


http://fossil-scm.org/index.html/leaves

And do a search for tags: trunk, you should find six instances of trunk 
leaves:

http://fossil-scm.org/index.html/info/b344d3c0cd
http://fossil-scm.org/index.html/info/9503a9152e
http://fossil-scm.org/index.html/info/b41feab774
http://fossil-scm.org/index.html/info/0072bfefd2
http://fossil-scm.org/index.html/info/4c931047ef
http://fossil-scm.org/index.html/info/4ba7b9c288

How'd that happen? Can/Should the open leaves 2-6 be closed?

:-?

-Martin
___
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] JSON API and WSDL

[Martin S. Weber]

On 09/14/11 11:21, Stephan Beal wrote:

Hi, all,

It would be cool if the JSON API had a way to serve a WSDL of its API.
i'm looking to pick someone's brain about WSDL, namely regarding:

a) Is WSDL intended only for SOAP (in which case it is not interesting
here)?


See section 4 [1] of the WSDL spec [2]. Short: there do exist http get/post 
bindings for WSDL; there is support for mimetypes, and thus application/json 
application/x-javascript text/javascript text/x-javascript (take your pick or 
use something completely different ;))


[1] http://www.w3.org/TR/wsdl#_http
[2] http://www.w3.org/TR/wsdl

-Martin
___
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] Presentation slides for Fossil?

[Martin S. Weber]

On 09/10/11 15:54, Ron Wilson wrote:

On Thu, Sep 8, 2011 at 4:08 PM, Ingo Kochingo.k...@gmx.de  wrote:

Take a look at
http://arnebachmann.pytalhost.de/pdf/integrated-version-control-with-fossil-scm.pdf


Good presentation.

I noted it said that configuration is not shared. Actually, it is
possible to share configuration between Fossil instances.


It wrongly claims that fossil is GPL.

-Martin
___
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] sqlite3_prepare_v2() is generating output to stderr?

[Martin S. Weber]

On 09/09/11 12:31, Stephan Beal wrote:

Maybe this is a bug, maybe not, but i've certainly never seen it before...

i'm intentionally introducing SQL errors to test my JSON-side error
handling, and i found that this:

rc = sqlite3_prepare_v2(g.db, zSql, -1, pStmt-pStmt, 0);

outputs to stderr when preparation fails.

i've never seen sqlite3 do that before. Is that normal? It interferes
with the JSON output:


Really? I'm assuming the JSON output goes to stdout, and the error message 
goes to stderr. In that case it wouldn't interfere with the JSON output at 
all. Just pipe the output to your json reader without a 21...there'll be no 
problem.


-Martin
___
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] sqlite3_prepare_v2() is generating output to stderr?

[Martin S. Weber]

On 09/09/11 12:34, Martin S. Weber wrote:

Really? I'm assuming the JSON output goes to stdout, and the error message
goes to stderr. In that case it wouldn't interfere with the JSON output at
all. Just pipe the output to your json reader without a 21...there'll be no
problem.


That being said, of course a library should never write to stderr directly.

-Martin
___
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] Draft doc for JSON/REST Fossil interface

[Martin S. Weber]

On 09/09/11 13:52, Stephan Beal wrote:

(...) While there
is arguably little use for JSON in CLI mode, i'm trying to keep it all
structured so that i can use the same code/commands in both CLI and
CGI/server modes (...)


Actually, if the complete CLI functionality was available as JSON output, we'd 
automatically have our library/frontend model. Think about it, a library is a 
backend that you communicate with. Typically you call functions in the same 
address space. The benefit of course is tight integration, compile time safety 
and what not. The drawback is becoming eminent when you are trying to access 
it from multiple callers / threads. Do you synchronize, what about locked DBs 
etc. etc.


Now, if your library is actually a server that you communicate with, and the 
CLI frontend-client is doing the same, anybody who's capable of sending a HTTP 
request to localhost can use all of fossils capabilities and program on top of it.


What would then be lacking, of course, would be the simple steps that e.g. 
sync, commit, list, mv, etc. are being composed of. That might be a 
not-so-herculian effort in the end to make fossil a library.


I haven't given this a lot of thought, just saying: in the end what we 
would want from a fossil library would be that a) the cli uses the same 
library so that we are able to be first-class citizens and b) finer grained 
control and c) a separation of concerns (you, fossil library, take care of the 
fossil stuff, I take care of invoking hooks, presenting a GUI and slapping my 
users if they try to do something stupid). a) to c) can be achieved with IPC, 
too, of course (just look at the COM/CORBA model, remove all the bloat and 
voila, you have data-format over protocol).


Btw, I suggest starting a new thread, called: FOSSILS JSON-RPC INTERFACE ;) 
Just to get REST out of people minds...


Regards,

-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] coding style guidelines: c89

[Martin S. Weber]

Hi,

fossil currently does not build in a ANSI C-89 environment - a requirement of 
the coding style guidelines ([1], point 16). There's an obvious build error in 
http_ssl.c (C++ style comments), but there's something more in sha1.c...
When adding a -std=c89 to the generated Makefile with gcc as the compiler, I 
end up getting (ignoring the C++ style comment at line 87)

./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token
./bld/sha1_.c:104: error: expected ')' before ':' token

(and many, many, many, many more lines like that). This seems to be because of 
the calls to asm() ... I don't know how to fix that. FYI, after preprocessing, 
the first instruction of line 104 looks like:


 qq[4]+=((qq[1](qq[2]^qq[3]))^qq[3])+(block[0] = (({ unsigned
int y; asm(rorl  %1,%0 : =r (y) : I (8), 0 (block[0]));
y; })0xFF00FF00) |(({ unsigned int y; asm(roll  %1,%0 :
=r (y) : I (8), 0 (block[0])); y; })0x00FF00FF))+0x5A827999+({
unsigned int y; asm(roll  %1,%0 : =r (y) : I (5), 0
(qq[0])); y; });

[1] http://fossil-scm.org/index.html/doc/trunk/www/style.wiki
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] cannot push or commit

[Martin S. Weber]

Try setting the autosync URL (fossil remote-url) to 
http://user@host:port/path. Note the presence of user in the URL.


-Martin
___
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] cannot push or commit

[Martin S. Weber]

On 09/01/11 12:30, Stephan Beal wrote:

On Thu, Sep 1, 2011 at 6:23 PM, Martin S. 
Webermartin.we...@nist.govmailto:martin.we...@nist.gov  wrote:
Try setting the autosync URL (fossil remote-url) to http://user@host:port/path. 
Note the presence of user in the URL.

To expand on that a bit:

if you clone with:

fossil clone http://USER:PASSWORD@host/... my.fsl

fossil will remember the authorization info but won't (unlike svn) reveal your 
password on stdout when shows you the URL later (e.g. via a pull/sync).


Sadly if you clone with http://USER@host/...my.fsl and enter the password in 
the prompt, it will *not* remember the password (at least last time I tried). 
What I do then afterwards is set the remote-url to the same one again, which 
triggers me being asked for a password, and *then* it's stored. Not sure 
whether that's fixed already or not, but it's on my inquiry-list :-)


-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Merge two repositories... not.

[Martin S. Weber]

So, I'm aware of drh's message from 2010-03-06 [1]. Is merging repositories 
this way still supposed to work? If so, I'll open a ticket with the 
information below. -Martin

[1] http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01641.html

# background: two teams working on some stuff, the fossil-using
# team working on something that ended up being a subset of the
# cvs-using team. Joerg's version of cvs2fossil made a fossil out
# of the unitsdb team (see below).
# The goal was to merge the resulting fossil with the subset that
# the prefixes_derived team was working on, resulting in a single
# fossil that contains both...

$ mkdir merge
$ cd merge  fossil open ../unitsdb.fossil
# ... snip, output deleted
$ fossil info
project-name: unnamed
repository:   /home/www/tmp/m/unitsdb.fossil
local-root:   /home/www/tmp/m/merge/
project-code: eeb7e06236b08dc4b57b6ab3b957fe5756c64f5b
server-code:  dc2df780602e6d8561d1a7280acbe4aabfe15ad3
checkout: df5c154920608f11c26a4a98f3d179b792b1ef94 2011-08-24 20:20:09 UTC
parent:   443c51cf173da58579e5457c7a634e3e51d85773 2011-08-18 15:58:06 UTC
tags: trunk
comment:  (Martin) Checkin before I munge everything.. (user: wwwpl)

$ cd ..
$ fossil sqlite3 -R prefixes_derived.fossil
SQLite version 3.7.7 2011-06-24 11:29:51
Enter .help for instructions
Enter SQL statements terminated with a ;
sqlite update config set value='eeb7e06236b08dc4b57b6ab3b957fe5756c64f5b' 
where name='project-code';
sqlite .quit

$ cd merge
$ fossil ui -P 12345 
$ cd ..
$ mkdir pd
$ cd pd
$ fossil open ../prefixes_derived.fossil
# snip and then
project-name: Prefixed and Derived units
repository:   /home/www/tmp/m/prefixes_derived.fossil
local-root:   /home/www/tmp/m/pd/
project-code: eeb7e06236b08dc4b57b6ab3b957fe5756c64f5b
server-code:  67266cf692b50dd078ffee601caf7f345fa3d243
checkout: cccd2619d9fb3724f96a806f55f443837dbc9bbe 2011-08-16 23:33:50 UTC
parent:   f3876370ba605de6706717018ee0f41dde9d4df0 2011-08-11 21:13:35 UTC
child:53c88f11df96c0156e9cbf3e0ba28905da261500 2011-08-16 23:38:07 UTC
tags: trunk

# project codes agree$ pwd
/home/www/tmp/m/pd
$ fossil push http://localhost:12345
 Bytes  Cards  Artifacts Deltas
Sent:7858169  0  0
Received:7928169  0  0
Sent:  295775322 14  1
Received:7270155  0  0
Sent:  274809307 16  0
Received:6518139  0  0
Sent:  273684292 15  0
Received:5813124  0  0
Sent:  286499289  3  0
Received:5672121  0  0
Sent:  338281281  8  0
Received:5296113  0  0
Sent:  325753276  5  0
Received:5061108  0  0
Sent:  294428269  6  1
Received:4732101  0  0
Sent:  267993199 25 45
Received:7129152  0  0
Sent:  251184169 14137
waiting for server...

Now. The server sits here eating 100% CPU and increasing its memory usage -- 
and not doing anything else. right now this is how it looks from top(1):

(pid user RR NI VIRT RES SHR %CPU %MEM TIME)
12375 wwwpl 33   8 2567m 1.3g  972 R 99.8 34.2   7:00.64 fossil 


This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC


___
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] Merge two repositories... not.

[Martin S. Weber]

On 08/24/11 18:14, Martin Gagnon wrote:
 May be fossil export of one piped on a fossil import of the other one will 
 work!!  I never tried but it might work I don't know how would look like 
 the timeline when doing that...


Actually I did try fossil deconstruct'ing both repositories into the same 
directory with reconstructing it afterwards. The progress reaching 102.1% made 
me think it picked up the rest, but it didn't. Note though that I did not 
adjust the project code before I did the deconstruct/reconstruct. Also I 
assume that a clash of hashes is unlikely, but not impossible this way (but, 
then again, I assume the same problem (or let's call it probability) exists 
for pushing content like drh suggested 1.5 years ago).

-Martin
___
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] Bug: errant operations don't cause exit(EXIT_FAILURE).

[Martin S. Weber]

On 08/09/11 15:14, Martin S. Weber wrote:
 I stumbled over this while I had a network outage...

...so what's the new workflow now that I as anonymous cannot create a ticket 
to capture that problem. Will I get an ACK on this list? Will a ticket be 
silently created by someone? Will there be a followup on this list once a 
problem-solving commit (or the decision it's not a bug, it's a feature) 
happened? This ought to be documented, IMO...

Regards,

-Martin
___
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] Bug: errant operations don't cause exit(EXIT_FAILURE).

[Martin S. Weber]

On 08/11/11 17:39, Richard Hipp wrote:
 There are 47 people on this list who have the appropriate credentials to
 write a ticket and/or make changes to the code.  All you have to do is
 convince 1 out of those 47 people that the problem is worth their time
 and effort.

 Or, failing that, you can fill out and send in a Copyright Release
 (http://www.fossil-scm.org/fossil/doc/trunk/www/copyright-release.html)
 and then you can become the 48th person with the credentials to write
 tickets and otherwise make changes, and then take care of the problem
 yourself.

 Yes, this all ought to be documented.  Once again, all you have to do is
 convince somebody that doing so is worth their time and effort.  Or you
 can send in a CLA and get the credentials to do it yourself.

Alright. I'll read the CLA carefully, try to become #48, take care of the 
problem myself if it hasn't been until then, and go ahead and document the 
procedure.

Thanks,

-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Bug: errant operations don't cause exit(EXIT_FAILURE).

[Martin S. Weber]

I stumbled over this while I had a network outage...

$ until fossil configuration pull all  fossil sync ; do echo; echo; date; 
echo; echo; sleep 5 ; done

 Bytes  Cards  Artifacts Deltas
Sent:  58  1  0  0
fossil: cannot connect to host server:port
Total network traffic: 0 bytes sent, 0 bytes received
Server:http://user@server:port/repo
 Bytes  Cards  Artifacts Deltas
Sent:3545 75  0  0
fossil: cannot connect to host server:port
Total network traffic: 0 bytes sent, 0 bytes received

Or in other words:

$ fossil sync
Server:http://user@server:port/repo
 Bytes  Cards  Artifacts Deltas
Sent:3545 75  0  0
waiting for server...fossil: cannot connect to host server:port
Total network traffic: 0 bytes sent, 0 bytes received
$ echo $?
0

Imho it should have exit status != 0 in the case where the network 
communication failed due to an error.

$ fossil version
This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC


Regards,

-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] X-Frame-Options http header

[Martin S. Weber]

So I wanted to use javadoc/scaladoc style documentation and take advantage of 
fossils embedded documentation -- I put the scaladoc under repo/docco and 
happily was going to http://server:port/repo/doc/trunk/docco/index.html - but 
there noscript was already waiting for me, saying No, no!. I couldn't 
convince it otherwise, so I turned the X-Frame-Options http header over to 
SAMEORIGIN instead of DENY and recompiled.

Now, with wikis and such I can see how there's a danger of IFRAMEs, click 
jacking and what not. On the other hand, there's a valid use-case for using 
iframes, where x-frame-options really should be SAMEORIGIN. Couldn't there be 
a setting to tune, or a list of glob patterns for which to turn 
X-Frame-Options to SAMEORIGIN (or, the other way round, to DENY) ?

(yeah yeah I know - obvious answer is stop using scaladoc or javadoc, they're 
bad tools anyways. But it's all I have here :)).

Regards,

-Martin
___
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] database locked on sync

[Martin S. Weber]

On 08/06/11 12:47, Kevin Quick wrote:
 $ fossil sync PATH-TO-REPO
   Bytes  Cards  Artifacts Deltas
 Sent:3897 82  0  0
 Error: Database error: database is locked
 DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private)
 Received: 118  1  0  0
 Total network traffic: 2225 bytes sent, 813 bytes received
 $

 This happens every time.  I found the suggestion for PRAGMA
 journal_mode=WAL; in sqlite mode, but that had no effect.

Actually, I've found that that happens when you have/try to open the same 
.fossil multiple times?

I.e. I have a server (fossil server ...) on host server; I use clients 
typically on boxens clientX (for X in ...); The procedure always was:
- fossil clone http://user@server:port/repo ~/open/repo.fossil
- mkdir ~/open/repo
- cd ~/open/repo
- fossil open ~/open/repo.fossil
- setup fossil remote-url (again;so that fossil actually asks for the pwd).

No problem ever. Auto-sync in all directions works charms.

But when I open the original fossil on server (say, it's lying in ~/fossilien, 
so I do:
- mkdir ~/open/repo
- cd ~/open/repo
- fossil open ~/fossilien/repo.fossil ) the open works fine, but any sync / 
update / whatever afterwards either comes up with COMMIT : DB locked or
the sql you have above: DB locked.

If, on the other hand, on the server, I replicate the clientX approach (that 
is, fossil clone http://user@localhost:port/repo ~/open/repo.fossil; fossil 
open repo.fossil) everything is fine.

So I think it's an issue with having file:/// level access open to a fossil 
repository multiple times / from multiple fossil instances? I'm just fishing 
the muddy waters here, but it's pretty obvious how to force the Database 
error: database is locked to appear to me.

Regards,

-Martin
___
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] database locked on sync

[Martin S. Weber]

On 08/08/11 16:16, Stephan Beal wrote:
 2011/8/8 Lluís Batlle i Rossell virik...@gmail.com
 mailto:virik...@gmail.com

 I have fossil repositories opened in multiple directories each, and
 I only hit
 database locked troubles if I'm really running at the same time
 two fossil
 operations on the same repository.

 So, I don't understand what happens in your situation.


 He's running a server on that same repo concurrently, and the server
 apparently locks the db for its whole life. The workaround is simply to
 use HTTP over localhost.

Actually, there seems to be more at play here. I tried replicating the problem 
on a toy (empty) repo, but failed. I mean I know how to handle myself (now ;)) 
without facing problems; if I succeed in having a nice clinical test-case that 
exhibits the same problems I'll let you know.

Regards,
-Martin
___
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 shunning: files reappear

[Martin S. Weber]

Hello there!

Recently I accidentally added some files that are automatically generated, 
changing quite often and which I generally don't want under version control at 
all. So I deleted them (I used show files on the timeline, followed the view 
links on the files I wanted to get rid of, used the shun link on the files, 
hit the shun button on the following page, and when I was done, I did an 
fossil rebuild bla.fossil on the shell. Then on my local copy of the thing, 
I used fossil configuration pull shun URL, followed by a fossil rebuild in 
my open checkout).

But when I'm looking at fossil status now, the files appear as:
EDITED path/to/file ...

I'm confused. I expected these files to be gone (from the view of fossil)? Is 
there anything else I should have done?

Here's a log of retrying it in a play fossil repository

server $ cd ~/my-fossils  # fossil is serving the directory
server $ fossil new tst.fossil
client $ fossil clone http://user@server:port/tst tst.fossil
client $ fossil open ./tst.fossil
client $ mkdir bla ; cd bla
client $ touch one
client $ fossil add one
client $ fossil ci
# after failure of auto-sync
client $ fossil remote-url http://user@server:port/tst
# enter password displayed on server for user
client $ fossil ci
# enter some message

# now, go to http://server:port/tst
# select timeline
# show files - view didn't work, so I clicked on the checkin's hash,
# selected the file and worked my way down until I had the shun link
# hit sun
# hit the shun button,
# see the shunned artifact id appear as a link
server $ fossil rebuild tst.fossil
# now the shunned artifact id no longer appears as a link
client $ echo change  one
client $ fossil configuration pull shun http://user@server:port/tst
# enter user password
client $ fossil status
# ... EDITED bla/one
client $ fossil rebuild
client $ fossil status
# ... EDITED bla/one

If I do a fossil ci now, it'll commit bla/one again, claiming it's a new file.

oh, and finally:

client $ fossil version
This is fossil version [6b5c797cc3] 2010-12-27 06:15:41 UTC
server $ fossil version
This is fossil version [d8221b9863] 2011-05-12 14:56:52 UTC

Pilot error? fossil version too old? bug in fossil and ticket appreciated?

Thanks in advance,

-Martin
___
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] Problem with shunning: files reappear

[Martin S. Weber]

On 07/13/11 17:05, Richard Hipp wrote:


 On Wed, Jul 13, 2011 at 5:02 PM, Martin S. Weber martin.we...@nist.gov
 mailto:martin.we...@nist.gov wrote:

 Hello there!

 Recently I accidentally added some files that are automatically
 generated,
 changing quite often and which I generally don't want under version
 control at
 all. So I deleted them (I used show files on the timeline, followed
 the view
 links on the files I wanted to get rid of, used the shun link on the
 files,
 hit the shun button on the following page, and when I was done, I did an
 fossil rebuild bla.fossil on the shell. Then on my local copy of
 the thing,
 I used fossil configuration pull shun URL, followed by a fossil
 rebuild in
 my open checkout).


 You probably also need to fossil rm the files from the manifest.

Ah. ok. So I deleted them (they all now show up as DELETED), I commit that, 
changing the files now won't show them as EDITED on a fossil status after 
changing them, although in the web interface in that changeset where I 
committed the deletions, they'll show up as Added filename version [] (the 
brackets are indeed empty and they are a link to url-prefix/artifact/ ) 
which is sorta confusing. Show diffs will show all of the files having empty 
content...

But the files now seem gone from fossil. Thanks for the help.

Regards,

-Martin
___
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] Version 1.18

[Martin S. Weber]

On 07/13/11 19:27, Richard Hipp wrote:
 I have tagged the release of Fossil version 1.18.  You can pickup a copy at

 http://www.fossil-scm.org/download.html

 Comments on the download page enumerate the changes in this release.
 This is no compelling reason to upgrade - it just had been a long time
 since there had been a release and so I felt I ought to do one.

 Yes, I know the OpenBSD binary is not available just yet.  I'm working
 on that

the configure script (yeah I know it's not necessary) bombs:

$ sh ./configure
jimsh: not found
Host System...i386-unknown-netbsdelf5.1.
Build System...i386-unknown-netbsdelf5.1.
C compiler... cc -g -O2
C++ compiler... c++ -g -O2
Checking for stdlib.h...ok
Checking for uint32_t...Checking for pread...ok
Checking for tclsh...ok
Checking for zlib.h...ok
Checking libs for inflateEnd...-lz
auto.def:77 missing close-bracket
in expression [check-for-openssl $msg...
missing close-bracket
in expression [check-for-openssl $msg...
 (parsing expression [check-for-openssl $ms...)
 invoked from within
if {[check-for-openssl $msg $cflags $ldflags} {
 incr found
 break
 }
 (foreach body line 11)
 invoked from within
foreach dir $ssldirs {
 if {$dir eq } {
 set msg system ssl
 set cflags 
 set ldflags ...
 invoked from within
if {$ssldirs ne none} {
 set found 0
 if {$ssldirs in {auto }} {
 catch {
 set cflags [exec pkg-config openssl --cflags-on...
 (file auto.def line 77)
 invoked from within
source $autosetup(autodef)
 (procedure main line 148)
 invoked from within
main $argv


Add the closing bracket on line 101 of auto.def to fix.

For those who are too lazy to build themselves, grab the stripped NetBSD (5.1) 
x86 binary ( fossil: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked (uses shared libs), for NetBSD 5.1, stripped ) from 
http://uharc.net/~phaeton/fossil-netbsd-x86-20110713.zip
SHA1:
e377f0f4b7dec7ece2650686c064e95b14e6  fossil-netbsd-x86-20110713.zip

Thanks @ Richard  contributors!

Regards,
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users