[fossil-users] persisting uv-files sync confusion

[j. van den hoff]

still struggling with this:

short version: `fossil clone' seems not to honour the `uv-sync' setting.

long version:

* server repo created while global `uv-sync' setting was still "off" (if  
this matters)


* server repo is not "open", i.e. no associated checkout (if this matters)

* server-side `uv-sync' global setting changed to "on" after creation of  
server repo (if this matters)


* client-side `uv-sync' global setting "on"

* from client, `fossil clone -u' does clone uv-files as expected

* from client, `fossil clone' does _not_ clone the uv-files despite  
manpage stating:


Setting: "uv-sync"
   If true, automatically send unversioned files as part
   of a "fossil clone" or "fossil sync" command.

* after opening the clone, `fossil sync' (w/o `-u') behaves as advertised  
and pull's the uv-files.


my fault or fossil's?

thank you
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

[fossil-users] Fwd: [fossil-src] activity alert

[j. van den hoff]

--- Forwarded message ---
From: fossil-...@fossil-scm.org
To: veedeeh...@gmail.com
Cc:
Subject: [fossil-src] activity alert
Date: Fri, 29 Jun 2018 13:40:12 +0200

This is an automated email sent by the Fossil repository at
https://fossil-scm.org/fossil to report changes.

== 2018-06-29 11:40:02 Check-In ==
Further wording enhancements to the on-line documentation to the
"fossil uv" command. (user: drh tags: trunk)
https://fossil-scm.org/fossil/info/c4ab8834218197fcc31b

sorry for nit-picking, but now it reads:

**add FILE ... Add or update unversioned files in the local
** repository so that they match FILEs on disk.
** Use "--as UVFILE" to give the file a different  
name

** in the repository than what it called on disk.
** Changes are not pushed to other repositories  
until

** the next sync.

"to give the file a different name in the repository than what it called  
on disk"


still seems wrong: a) since there might be multiple files, not only a  
single one (question: does `--as' only work with a single file or can it  
be specified multiple times?), b) "than what it called on disk" seems  
grammatically challenged... how about


"to give a file a different name in the repository than what it is called  
on disk"  (or simply "... than on disk")?


thank you,
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] typos in `fossil help uv'

[j. van den hoff]

this has been addressed recently but not completely. there are still some  
glitches:


12,16c12,16
< repository so that it matches FILE on disk.
< Use "--as UVFILE" to give the file a different  
name

< in the repository than what it called on disk.
< Changes are not pushed to other repositories  
until

< the next sync.
---

repository so that they match FILEs on disk.
Use "--as UVFILE" to give a file a different name
in the repository than on disk. Changes are not
pushed to other repositories until the next
sync.





On Wed, 27 Jun 2018 14:57:43 +0200, j. van den hoff  
 wrote:



patch for `fossil help uv' output:

11,12c11,12
<add FILE ... Add or update an unversioned files in the local
< repository so that it matches FILE on disk.
---

   add FILE ... Add or update unversioned files in the local
repository so that they match FILE ... on disk.

14c14
< in the repository than what it called on disk.
---
in the repository than what it is called on  
disk.

42c42
< of each file is propagate to all repositories  
and

---
of each file is propagated to all repositories  
and



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil set uv-sync question

[j. van den hoff]

I am still struggling with unversioned files: after "discovering" the  
uv-sync setting I tried it out:


* on the server I did `fossil set --global uv-sync on'.

* doing, then, a file system based clone on the server `fossil clone  
{path_to_server_repo} {path_to_clone_in_server_file_system} works as  
expected (uv-files cloned as well), fine. BUT


* doing from the remote machine (after setting `uv-sync on' there, too)  
`fossil clone {ssh-transport:path_to_server_repo} {path_to_local_clone}  
does not work: the uv-files residing in the server repo are still not  
synced/cloned. they appear only after opening the clone and issuing  
`fossil sync' again (so the local uv-sync setting, then, actually *is  
recognized*.


question 2: should not the clone via ssh-transport from the remote  
machine, too, clone the uv-files just as the file system based clone on  
the server side?


if it matters: the server-side repo had been created while `uv-sync' was  
still off. (question 3: does a closed repo have "local" settings? where  
are they stored? can't find them  in the schema...)


thank you,
joerg


PS: uv-sync seems nowhere to be mentioned (let alone explained) in the  
command line help (only found it in the GUI). maybe it should be  
mentioned/explained in `fossil help uv'? also, the current explanation  
reads:


If true, automatically send unversioned files as part
of a "fossil clone" or "fossil sync" command.  The
default is false, in which case the -u option is
needed to clone or sync unversioned files.

it was not obvious from this text whether the server-side or the  
clone-side setting is relevant ("if true, automatically send..." seems to  
indicate it's the server-side, but actually it is the clone-side). maybe  
this could be rephrased?


--
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] `unversioned' questions

[j. van den hoff]

On Wed, 27 Jun 2018 17:48:43 +0200, Andy Goth   
wrote:



On 06/27/18 03:50, j. van den hoff wrote:
but doing it via shell commands remains a hack/workaround. fossil  
providing functionality to treat uv-files and tracked files mostly on  
equal footing during ci/co/up/push/pull/sync (considering, of course,  
that there is no history/no deltas for uv-files) would be much better.


You can set the ignore-glob to make Fossil's versioned commands ignore  
the unversioned files.


yes, that's right (in fact, I did that right from the start), but that's  
not the issue. rather, the problem (or missing feature...) is the absence  
of a setting/capability to handle uv-files and tracked files "identical"  
as far as possible regarding sync/update between repository and checkout.  
I've tried to explain in previous mails why I would find that useful.







--
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] typos in `fossil help uv'

[j. van den hoff]

patch for `fossil help uv' output:

11,12c11,12

Re: [fossil-users] `unversioned' questions

[j. van den hoff]

On Tue, 26 Jun 2018 18:58:42 +0200, Andy Goth   
wrote:


I think the next project that needs this feature should write a utility  
script for themselves that uses the uv commands to extract files however  
makes sense for them.


well, AFAIAC, I would be happy if fossil would support the equivalent of  
this shell one-liner:


for i in $(fossil uv ls); do fossil uv export $i $i; done

(plus, possibly checking whether there is any need to extract the file(s)  
again (local copy more recent or older than time stamp in the  
`unversioned' table?).


as explained previously, the use case in mind primarily would be a project  
where all uv-files reside somewhere within the checkout.


as an aside: it is really very nice that `fossil uv export' silently  
creates missing target directories (recursively, too) i.e. does something  
like `mkdir -p' implicitly. so the shell command above works even in a  
pristine clone.


but doing it via shell commands remains a hack/workaround. fossil  
providing functionality to treat uv-files and tracked files mostly on  
equal footing during ci/co/up/push/pull/sync (considering, of course, that  
there is no history/no deltas for uv-files) would be much better.


if that collides with the original intent of `uv' (and support of uv-files  
_outside_ of the checkout dir is crucial -- so that it might not be always  
a good idea to "flood" the file system at random places with copies of the  
uv-files), one or two settings controlling the behavior of `uv' related  
stuff still would be possible. in principle at least...



--
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] `unversioned' questions

[j. van den hoff]

On Tue, 26 Jun 2018 18:58:42 +0200, Andy Goth   
wrote:


I think the next project that needs this feature should write a utility  
script for themselves that uses the uv commands to extract files however  
makes sense for them.  This live experimentation is necessary to figure  
what is needed in practice.  No one is forced to wait for any changes to  
be made to Fossil itself.  One day, a set of best practices (i.e., a  
vague consensus on which compromises and heuristics most people can live  
with most of the time) will emerge, at which point Fossil can adopt them  
as useful defaults, but people should always be able to write new  
scripts that work best for their specific projects.


On 06/26/18 10:31, Richard Hipp wrote:

My thought was to provide a new setting (perhaps versionable) that
specified a directory relative to the root of the check-out into which
unversioned files are written whenever one does "fossil update" or
"fossil checkout".  If the setting is missing or empty, then Fossil
works as it does now.  If you turn on the setting, though, then the
unversioned files work just like other files in the check-out, except
that Fossil never records their history.


I overall like the idea, but I can envision an endless stream of feature  
creep as people want to do any of the following and more:


- Deal with files having platform-incompatible names (slashes,  
backslashes, drive letters, characters unsupported by the filesystem)

- Extract only files within certain size ranges
- Extract only files within certain date ranges
- Extract only files matching certain glob patterns
- Update the unversioned files when checking in
- Get diffs showing which unversioned files have changed
- Handle new files being added to the unversioned directory
- Reverse filename mapping done for platform compatibility when checking  
in or adding new unversioned files
- Selectively check in unversioned files along with the rest of the  
check-in


And on it goes.  All of the above can be done today via shell scripts,  
so projects wanting to experiment are invited to get started right away.


I dislike feature creep and endless "please implement this for me"  
requests, too. but I don't think this argument applies here, really.  
anyway the developer(s) decide what they implement and what not...


from this thread I have learned in the meantime, that uv-files where  
intended for something different than what I would have guessed ("created  
for the purpose of providing a place to store build products when Fossil  
is used as a server") and that uv-files usually(is that right?) are  
residing outside of the checkout. so be it. and then I can understand why  
fossil does what it does with uv-files (and what it does not, namely  
providing a `fsl uv up' command that would do the same with uv-files that  
`fsl up' does with versioned files.


all the possible issues with file system /OS issues etc. are sure valid  
but to the extent that fossil handles these with versioned files it could  
do the same with uv-files (at least as long as their pathnames are  
relative to the checkout root).


so my question would be:

is their any strong argument against a `fossil up -u' command? would it be  
undesirable to have? (if it really is going to be implemented und whether  
drh is willing to invest the time is a different question, naturally.) I  
think it would be quite valuable for assorted projects, notably those  
depending on large binary files such as jpeg-images (or libs) that are  
*project-specific* and prone to multiple changes over the duration of the  
project but where tracking changes of these files is not required. I  
simply would find it useful to be able to do `fsl up; fsl up -u' (or both  
with a single command) in order to bring my checkout including uv-files up  
to date...


and yes, I will write a shell or TCL script to do this, if everything else  
fails. but it will be inferior to integration of this feature into fossil.







--
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] `unversioned' questions

[j. van den hoff]

On Tue, 26 Jun 2018 18:33:22 +0200, Stephan Beal   
wrote:



On Tue, Jun 26, 2018 at 5:45 PM  wrote:


​Can unversioned files respect their original paths when added?
I have several locations for bitmaps, icons, pdf's, etc.
They do not necessarily reside in an isolated folder.​


yes, same here, *but* in directories *within* the checkout dir.





That wouldn't work cross-platform. You might store file the C:\D\e\f.txt

which i could not extract on Unix because we don't have drive letters. If
we ignore the C: part, i still couldn't extract to /D/e/f.txt, unless i  
was

the root user. Case sensitivity is another problem in that regard. If you
store C:\D\e.txt and C:\d\e.txt, those would map to two different folders
on Unix systems.

Likewise, Unix /a/b/c.txt has no direct mapping on Windows (which drive
should it use?).


I was only thinking about *relative* pathnames w.r.t. checkout root and  
that sure could be managed with the same logic cross-plattform as  
versioned files, right?


but as explained, I have not used uv-files until today (and have not  
followed the discussion closely, when it was implemented). so I do not  
know all the use cases that are of relevance here.


I now -- in view of your mail -- understand of course that there could be  
use cases (possibly the majority) where uv-files are located somewhere  
else in the file tree, rather than in the checkout. no idea how these  
should be properly handled, than. probably the way DRH just proposed would  
than be the only way.


o.t.o.h.: the special case, where *everything* (versioned and unversioned  
files) reside together in the checkout dir might deserve special  
consideration/handling. it seems to me the "logical" extension/next step  
beyond "put everything under revision control": still keep all the stuff  
that constitutes "the project" together in one place (the checkout dir),  
but decide which files could be handled as uv-files in order to safe on  
disk space/repo size.


this would imply special handling of the case "`fossil uv ls'" reports  
relative, rather than absolute pathnames" but maybe it could be quite  
useful, just think of my simple example: a LaTeX doc including several  
project-specific image files that I do not want to keep under revision  
control but as part of the repo. the tex-file will no longer compile on  
"the other side" if the uv-files are not put back into the expected  
(relative) location...







--
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] `unversioned' questions

[j. van den hoff]

On Tue, 26 Jun 2018 18:12:54 +0200, Richard Hipp  wrote:


On 6/26/18, j. van den hoff  wrote:

turning this setting on by default might also offer the "least
surprise" for the user


It isn't an on/off setting.  I was not clear. The setting is the name
of the directory that is the root of the unversioned file hierarchy.


see my previous mail: from a user perspective (mine, anyway...) it seems  
that the only "good" solution would be that the uv-files end up at the  
exact same place as on the "pushing" site/repo, i.e. under the pathname  
that is recorded in the database and reported by `fossil uv ls'. in my  
view, uv-files are not different from any other file in the repo, except  
that there history is not recorded. so they should not change location in  
my checkout, depending on a setting. they should keep their logical  
position (pathname relative to checkout root).




An empty string for this setting means "off".  But there are
infinitely many "on" settings.  What should be the default?
"unversioned"?  ".uv"?  Just "."?


this could of course work if the path convention is obeyed also by the  
"pushing" repo (that checks the uv-files in) even before checking the  
files into the repo (think of my example: file names of the unversioned  
files are used in some "include" statement elsewhere, e.g. in our LaTeX  
document). but it seems error prone. also, there might be good reason for  
multiple directories containing (e.g. different types of) uv-files.


why could the uv-files not "simply"(?) be always put into the locations as  
reported by `fossil uv ls'. am I overlooking some obvious problem? I would  
think that could be the only thing a user would want: uv-files are always  
located/put where they "should be" (namely at the location where they were  
prior to checking them in in one of the clones) just as the versioned  
files?


if unversioned files are moved around in the checkout manually, the  
changed paths should be propagated with the next `uv sync' to the other  
side/everywhere. I presume...



--
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] `unversioned' questions

[j. van den hoff]

On Tue, 26 Jun 2018 17:31:32 +0200, Richard Hipp  wrote:


My thought was to provide a new setting (perhaps versionable) that
specified a directory relative to the root of the check-out into which
unversioned files are written whenever one does "fossil update" or
"fossil checkout".  If the setting is missing or empty, then Fossil


fyi, in our today's "test case", the unversioned files reside in a  
designated sub-directory of the checkout root *plus* in sub-directories  
thereof. I presume, this is typical: it might not always be desirable (or  
feasible) to put *all* unversioned files (there might be many...) in a  
common, single directory. moreover, in our test case, these files are  
image files whose path appears in the `\includegraphics' directives in the  
LaTeX file using them: so they must not change their location relative to  
the checkout root ...


overall, I would think the handling of unversioned files needs always to  
respect the (recorded) original path relative to the repo root (as also  
reported by `fossil uv ls'). anything else might break builds (of latex  
docs or programms), no?



works as it does now.  If you turn on the setting, though, then the
unversioned files work just like other files in the check-out, except
that Fossil never records their history.


such a setting (even if not versionable) would be an ideal solution in my  
view. turning this setting on by default might also offer the "least  
surprise" for the user (it sure surprised us here today that the files  
simply did not show up in the other working copy at all ...)




I'm not sure yet whether or not this is a good idea.  I'll need to
think about it.


see above: my opinion is, that the location of the files should be as  
reported by `fossil uv ls', i.e. unchanged relative to checkout root. I do  
hope, this would not cause trouble elsewhere for fossil or complicate  
implementation too much?


thank you for bothering to look into this.

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] `unversioned' questions

[j. van den hoff]

On Tue, 26 Jun 2018 17:08:48 +0200, Richard Hipp  wrote:


Unversioned files do not appear in the local check-out, by design.  It
would be an enhancement to make them do so.

But you are not the first to request that capability.  I've been on a
Fossil-enhancement binge lately - perhaps I can find the time to fix


that has not gone unnoticed :)


that for you...


this would be great, of course, if doable. I actually was  
suspecting/"afraid" that the current behavior is by design and that there  
might be deeper reasons for it ... but when I discussed this with my  
colleague we were not able to find an example were providing `up -u' or  
`uv up' could cause a problem. could it?




On 6/26/18, j. van den hoff  wrote:
today I convinced a colleague to give fossil a try. so we set up a  
project

(two checkouts/clones, one central server/repo), using a planned journal
article (to be written in latex) as the test case.

now, while I never have used 'unversioned files' so far, he immediately
wanted to try this option for the jpeg-figures to be included (and
probably modified 100 times before the paper is completed).

good: he managed to get them into his repo and to sync it to the server.
good: I managed to sync the unversioned files into my repo.

problems/questions:

1.
the files do not materialize in my checkout after "sync -u". they are
"just" present in my local repository. that probably is as it should be
(just as with standard `sync'). but there seems to be no equivalent to
`fossil up' for the unversioned files.

question: what is the canonical way to get them out of the repo? I see  
the
export command but it probably is not the idea to issue 20 export  
commands

(or to write a shell script for that)?

2.
if I export the files manually now, what happens after the next push of
unversioned files by my colleague? I guess, I can sync them (but am not
really notified of changed content) but would have again to export them
manually (and would have to know that this is required)?

maybe I am missing some stupid point here, but my expectation would have
been that unversioned files mostly behave like tracked/versioned files  
in

that there should be an update facility (say `fossil up -u' or something
like that) of these files in my local checkout?

thank you,

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







--
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] `unversioned' questions

[j. van den hoff]

today I convinced a colleague to give fossil a try. so we set up a project  
(two checkouts/clones, one central server/repo), using a planned journal  
article (to be written in latex) as the test case.


now, while I never have used 'unversioned files' so far, he immediately  
wanted to try this option for the jpeg-figures to be included (and  
probably modified 100 times before the paper is completed).


good: he managed to get them into his repo and to sync it to the server.
good: I managed to sync the unversioned files into my repo.

problems/questions:

1.
the files do not materialize in my checkout after "sync -u". they are  
"just" present in my local repository. that probably is as it should be  
(just as with standard `sync'). but there seems to be no equivalent to  
`fossil up' for the unversioned files.


question: what is the canonical way to get them out of the repo? I see the  
export command but it probably is not the idea to issue 20 export commands  
(or to write a shell script for that)?


2.
if I export the files manually now, what happens after the next push of  
unversioned files by my colleague? I guess, I can sync them (but am not  
really notified of changed content) but would have again to export them  
manually (and would have to know that this is required)?


maybe I am missing some stupid point here, but my expectation would have  
been that unversioned files mostly behave like tracked/versioned files in  
that there should be an update facility (say `fossil up -u' or something  
like that) of these files in my local checkout?


thank you,

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] mv-rm-files setting

[j. van den hoff]

perfect, thanks a lot!

On Tue, 26 Jun 2018 13:22:40 +0200, Richard Hipp  wrote:


The mv-rm-files setting used to require a compile-time option in order
to function.  I have removed that requirement.  mv-rm-files now works
without special compile-time options.

On 6/26/18, j. van den hoff  wrote:

I have not fiddled with this for some time and now I do no longer recall
how exactly this setting is managed. it is mentioned in several of the
help pages and I do have an entry
in my global `.fossil' database

INSERT INTO global_config VALUES('mv-rm-files','on');

(I do no longer recall when and how I've put it there :| ...) but it is
neither reported by `set' AFAICS nor, in fact, does `fossil set'  
recognize

"mv-rm-files" as a valid setting. what am I missing? a pointer where to
look in the documentation would be appreciated...

thank you,

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







--
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] mv-rm-files setting

[j. van den hoff]

I have not fiddled with this for some time and now I do no longer recall  
how exactly this setting is managed. it is mentioned in several of the  
help pages and I do have an entry

in my global `.fossil' database

INSERT INTO global_config VALUES('mv-rm-files','on');

(I do no longer recall when and how I've put it there :| ...) but it is  
neither reported by `set' AFAICS nor, in fact, does `fossil set' recognize  
"mv-rm-files" as a valid setting. what am I missing? a pointer where to  
look in the documentation would be appreciated...


thank you,

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] email testing - no subscriber table?

[j. van den hoff]

On Mon, 25 Jun 2018 23:57:35 +0200, jungle Boogie  
 wrote:



On 25 June 2018 at 14:51, Richard Hipp  wrote:

On 6/25/18, jungle Boogie  wrote:

If I inadvertently forward my email along
to someone/group without modifying the footer, the person/group would
be able to alter my subscription.


How can I fix that?


it seems the only way would be to _not_ include the link in each and every  
alert, no? maybe automated separate notification mail once every (3?)  
months ("your subscription details are here:") would be feasible? many  
mailing lists do the same (mailing subscription password reminders once a  
month or every 3 months). o.t.o.h.: it is of course not really a big deal  
to leave it as is (but the unintentional dissemination of the subscription  
links via forwarding the alert mails will then happen regularly, of  
course).



--
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] email testing - no subscriber table?

[j. van den hoff]

On Mon, 25 Jun 2018 05:08:53 +0200, Andy Goth   
wrote:



On 06/24/18 05:27, j. van den hoff wrote:
additionally, mabye shorten the footer separation line to exactly two  
`--', treating the footer as the sender's "affiliation/identity" (which  
usually leads to a less prominent display by the email client).


If you're talking about email signatures, they are preceded by the magic  
character sequence dash-dash-space-newline.


right. actually, I was not aware of the mandatory space before the  
newline. thank you.







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] email testing - no subscriber table?

[j. van den hoff]

On Sun, 24 Jun 2018 12:22:07 +0200, Richard Hipp  wrote:


On 6/24/18, j. van den hoff  wrote:

On Sun, 24 Jun 2018 12:08:30 +0200, Richard Hipp  wrote:


The UPDATE syntax error should be fixed now.  Please try it again.


yes, it works now. thank you. NB: I received the notification email
regarding the fix prior to actually confirming the subscription again --
so my confirmation went through despite the SQL error? or is this
indication of some flaw in the subscription logic?



You had already been verify by the fact of visiting the page itself.
That was a separate UPDATE (with the correct syntax!) that was
performed in a different transaction.

Thanks for pointing this out, though.  I did have to think about it
for a few seconds.


thanks for this explanation...

regarding the format/wording of the notification, it currently reads:

8<--
This is an automated email sent by the Fossil repository at  
https://fossil-scm.org/fossil to report changes.


== 2018-06-24 10:07:29 Check-In ==
Fix an SQL syntax error. (user: drh tags: trunk)
https://fossil-scm.org/fossil/info/0398e41aa6f72c0da60b


Subscription info: https://fossil-scm.org/fossil/alerts/*
8<--

personally, I would prefer to simply omit the first line or to put it at  
the bottom of the footer, since I would recognize the nature of the mail  
without this explanation, so it's essentially explaining the obvious and a  
minor distraction from the actual content of the mail (and the repos  
identity can also be taken from the `subscription info' link).


additionally, mabye shorten the footer separation line to exactly two  
`--', treating the footer as the sender's "affiliation/identity" (which  
usually leads to a less prominent display by the email client).





--
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] email testing - no subscriber table?

[j. van den hoff]

On Sun, 24 Jun 2018 12:08:30 +0200, Richard Hipp  wrote:


The UPDATE syntax error should be fixed now.  Please try it again.


yes, it works now. thank you. NB: I received the notification email  
regarding the fix prior to actually confirming the subscription again --  
so my confirmation went through despite the SQL error? or is this  
indication of some flaw in the subscription logic?




On 6/24/18, j. van den hoff  wrote:
I get an sqlite error when following the verification link and hitting  
the


`submit' button there:

SQLITE_ERROR: near "WHERE": syntax error

Database Error
near "WHERE": syntax error: {UPDATE subscriber SET sdonotcall=0,
sdigest=0, ssub='c', smtime=julianday('now'), smip='*', WHERE
subscriberCode=hextoblob('*')}


On Sat, 23 Jun 2018 22:07:52 +0200, Richard Hipp  wrote:


Just FYI:

I have opened up email notifications on the canonical Fossil
repository.  To subscribe, visit:

https://fossil-scm.org/fossil/subscribe

Your help in finding creative ways of breaking the new system is
appreciated.

Please note that this is still a work-in-progress.  All subscription
data may be erased at any time.  Email notifications might be disabled
at any time, in order to close security holes or otherwise work on the
system.



--
Using Opera's revolutionary email client: http://www.opera.com/mail/







--
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] email testing - no subscriber table?

[j. van den hoff]

I get an sqlite error when following the verification link and hitting the  
`submit' button there:


SQLITE_ERROR: near "WHERE": syntax error

Database Error
near "WHERE": syntax error: {UPDATE subscriber SET sdonotcall=0,  
sdigest=0, ssub='c', smtime=julianday('now'), smip='*', WHERE  
subscriberCode=hextoblob('*')}



On Sat, 23 Jun 2018 22:07:52 +0200, Richard Hipp  wrote:


Just FYI:

I have opened up email notifications on the canonical Fossil
repository.  To subscribe, visit:

https://fossil-scm.org/fossil/subscribe

Your help in finding creative ways of breaking the new system is  
appreciated.


Please note that this is still a work-in-progress.  All subscription
data may be erased at any time.  Email notifications might be disabled
at any time, in order to close security holes or otherwise work on the
system.



--
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] What should email notifications look like?

[j. van den hoff]

On Fri, 22 Jun 2018 16:46:07 +0200, Marcelo  wrote:

El vie., 22 jun. 2018 a las 11:09, jungle Boogie  
()

escribió:



I'd rather have emails delivered in plain text, bypassing
html/markdown but that's just my preference.



​+1 for plain text notifications.



+1


--
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] How to fix an SQLite warning on the /tagtimeline page?

[j. van den hoff]

I see it on some repos, but not on others...

On Fri, 23 Mar 2018 14:43:12 +0100, Martin Gagnon  wrote:


On Fri, Mar 23, 2018 at 01:02:47PM +0200, Svyatoslav Mishyn wrote:

Hi,

how to fix an SQLite warning on the /tagtimeline page?

On all my publicly available repositories I have such error on that  
page:

SQLITE_WARNING: automatic index on tagxref(tagtype)



I have the exact same problem in all my repo.

I didn't notice it before, probably because I didn't look at this page
for a while.

  Fossil Version on Server (OpenBSD i386):
Fossil 2.5 [188a0e2904] 2018-02-07 18:48:14





--
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] Compilation failure on osx 10.10 for fossil and sqlite shell

[j. van den hoff]

On Fri, 12 Jan 2018 15:37:41 +0100, Richard Hipp  wrote:


On 1/12/18, Marcel Graf  wrote:


I tried to compile actual tip of trunk (c409f828) on OS X 10.10.5

It fails when on the linking stage:
Undefined symbols for architecture x86_64:
  "_utimensat", referenced from:


There is a new trunk version available.  Please try again and report
your results.  Thanks.


works again (at least form me, using OSX 10.12).

thank you


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 120, Issue 2

[j. van den hoff]

On Tue, 02 Jan 2018 04:33:56 +0100, Stephan Beal   
wrote:



(this time back to the list)
On Tue, Jan 2, 2018 at 3:43 AM, Andy Bradford 
wrote:


Thus said Stephan Beal on Tue, 02 Jan 2018 03:07:20 +0100:

> That will  still strip  any newlines from  his input,  though, because
> that's how $(...) works.

It actually only strips the trailing newline. Any newlines in the middle
of the file are fine.



That's not what i'm seeing:

[stephan@host:~]$ echo -e "1\n2\n3"
1
2
3
[stephan@host:~]$ echo $(echo -e "1\n2\n3")
1 2 3


you would need echo "$(echo -e "1\n2\n3")" here to protect the embedded  
newlines in the outer echo's output command expansion does not mess  
with the newlines, really. as andy said, it strips only trailing ones.








--
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] A-B comparison of proposed timeline changes

[j. van den hoff]

On Tue, 05 Dec 2017 16:27:28 +0100, Richard Hipp  wrote:

Please keep a close eye on the Fossil website and report any usability  
issues.


just a thought: could/should the boxes+checkin messages be indented,  
reflecting the horizontal position of the respective branch in the  
timeline graph (specifically, keeping the horizontal distance from the  
respective timeline graph bullet to the box constant for all branches)? I  
am aware that one would sacrifice some horizontal "real estate" by this,  
if there are many open branches (e.g. http://core.tcl.tk/tcl/timeline),  
but actually most ci messages are short so that would not cause too many  
line breaks. I could imagine
that indenting would help to read through the contiguous ci messages of a  
certain branch a bit on top of what the color coding provides, especially  
for instances for the colors are recycled for different branches, e.g.  
here:


http://core.tcl.tk/tcl/info/dcc6f04732c93947

any thoughts?

thx,
joerg


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] More timeline changes

[j. van den hoff]

On Sat, 25 Nov 2017 23:51:23 +0100, Marc Simpson  wrote:


One other (potential) problem: without the hash prefix, descriptions
run together.
Example: http://www.sqlite.org/src/timeline, 2017-11-24. The graph
nodes are flushed to the left, so descriptions appear as:
 Add the "^" syntax from fts3/4 to fts5. ...
  Enhance the configure script to detect zLib. ...
It's not immediately clear that these are separate commits given the
amount of horizontal space; adding a bit more vertical padding or
boxing descriptions (perhaps with alternating colours) might help?


+1

--
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-NG Bloat?

[j. van den hoff]

On Fri, 24 Nov 2017 15:25:25 +0100, Richard Hipp  wrote:


On 11/24/17, Johan Kuuse  wrote:


I think 'push' and 'pull' seems fair enough.
But what about 'rebase' and 'submodule'?
To what level should the Fossil-NG client support Git features not
present in Fossil?


Zero.


a good thing in my view ... but, consequently, users will run into the  
"impedance mismatch" problem between the different systems mentioned by  
several others, no?






If not supported, wouldn't there be a risk of users just sticking to
'git rebase' instead?



If users want to rebase, then they can use their Git client.


as they could for the rest of their interaction with the git repo. I  
presume exactly that will happen: existing primary git users won't switch  
to a different "git client" anyway. fossil users probably _would_ use the  
ability of fossil-NG to talk to a git repo, though, as long as they don't  
need to do git-specific fancy stuff. but I question whether implementing  
this ability could increase the user base notably.







--
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] A-B comparison of proposed timeline changes

[j. van den hoff]

On Fri, 24 Nov 2017 15:35:55 +0100, Richard Hipp  wrote:


Which is better?

  A:  https://www.fossil-scm.org/a/timeline
  B:  https://www.fossil-scm.org/b/timeline

Also:

  A: https://www.fossil-scm.org/a/finfo?name=src/search.c
  B: https://www.fossil-scm.org/b/finfo?name=src/search.c

Surf about from any of the links above for additional views.

The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.

In the recent HN discussion of Fossil
(https://news.ycombinator.com/item?id=15752725) some comments were
sharply critical of the timeline display in Fossil. While I think
those comments were overly dramatic, they did bring up the point that
the check-in comment is probably the most important feature and should
be more prominent.  This A/B comparison is my attempt to make them so.

Further suggestions and/or comments are welcomed.


in my view, variant B might be preferable somewhat (for the GUI -- but  
leaving the timeline output in the terminal as is...). but choosing some  
pale color shades (or alpha?) makes the text difficult to read. I would  
prefer a smaller font instead, leaving the colors untouched.


personally, I rather like the tidiness of the timeline graph available in  
mercurial via `hg serve' which beyond the checkin message hides everything  
except time of checkin, branch name, and user (and uses a distinctly  
smaller font size for the latter info). in effect one mostly notices the  
checkin message easily. so one might think about doing something similar  
(remove hash display and link the commit message itself to the 'chekin'  
page)?


just an idea


--
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-NG Bloat?

[j. van den hoff]

On Thu, 23 Nov 2017 01:09:21 +0100, Richard Hipp  wrote:


On 11/22/17, Offray Vladimir Luna Cárdenas  wrote:

I'm dubious over making Fossil a client for
any other main DVCS out there.


But making Fossil work as a client for Git is the cornerstone of my
plan for world domination!  :-)

One important reason that many people use Git is because so much OSS
is hosted on GitHub and everybody wants to be part of the action.  If
developer Alice wants to play in the OSS world, she has to use Git.
But if Fossil were able to clone, push, and pull from Git
repositories, that would enable Alice to use Fossil instead, opening
the door to wider adoption.


this might be true, but ...

1.
mercurial has tried this (for many years there have been extensions to use  
it as a client for git and subversion) and it does not seem to have  
increased adoption of mercurial substantially (probably not at all but who  
knows?). this is my major concern: if one can extrapolate from the hg  
story, chances for massively (or even modestly) increasing the fossil user  
community by making it work as a git client might be slight. a poll on  
github would be interesting (if it were possible): how many users are  
using hg locally to talk to github?


2.
my use of the mentioned hg-extensions with git and svs led to assorted  
problems for the simple reason that functionalities of the different  
systems do not map one-to-one. so one has continuously to remember that  
one is working in a (local) hg clone that will sync against a remote git  
or svs repo in the end and to observe the necessary restrictions. this  
makes it potentially more difficult and error prone than using the other  
tool directly. it is not necessarily a good "PR move" for a inherently  
superior/easier system one wants to push.


of course, if your plans come to fruition, I still would be happy to use  
the new functionality if it helps to reduce the pain of working with git  
repos. I am just skeptical regarding effort invested vs. benefit gained.  
other things would be further up on my wish list, e.g. history  
tracking/finfo across renames, full grep of content across revisions (hg  
does this very nicely, e.g.).


and (of course): thanks for fossil

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] feature request: diff -tk: 'q' to quit

[j. van den hoff]

On Sun, 12 Nov 2017 01:08:32 +0100, Stephan Beal   
wrote:



Lol - i never even noticed that there was a search box in the diff view.

i'd be just as happy with ctrl-q - anything which is left-hand friendly.


but `q' alone is better ;-). and the mentioned patch works nicely as I  
just checked...


in this context: there is a further minor problem with the tk-diff in not  
starting up in the presence of otherwise innocuous warnings. at least I  
see this after `fossil diff -tk' in a certain checkout:


8<
'setting binary-glob has both versioned and non-versioned values: using  
versioned value from file ... ... or delete the non-versioned setting with  
"fossil unset binary-glob")'

while executing
"close $in"
(procedure "readDiffs" line 7)
invoked from within
"readDiffs $fossilcmd"
("eval" body line 1)
invoked from within
"eval $prog"
(file "file-4c406fbfbef75d4b" line 471)
8<

barebones `fossil diff' just shows the differences despite the  
'binary-glob' warning as it should... I had a short look at diff.tcl but  
do not see the reason for the above (apparent: the start of the tcl error  
message seems to be missing from the output...) exit-on-error. any ideas?


joerg






- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity,  
typos,

and top-posting.

On Nov 12, 2017 01:06,  wrote:



Stephan Beal  writes:
> Sometime in the far past, tapping 'q' (or maybe it was 'x') in the  
diff

-tk
> widget used to exit that widget. Nowadays one has to click the "Quit"
> button or tap Alt-F4 (a really finger-clumsy holdover from early  
Windows

> versions).

It was 'q'. It was removed by
http://fossil-scm.org/index.html/info/f6d9583173cbd6d2

It missed it so much that I use a for that patched fossil.

> Can we please, please, please get the 'q'==>quit functionality back?  
It
> sounds like a trivial thing to add, but the tcl code is all Greek to  
me

:/.

I second that plea.

I still use the proposed patch from

https://www.mail-archive.com/fossil-users@lists.fossil-scm.
org/msg24885.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] strange problem with graphical diff

[j. van den hoff]

On Wed, 23 Aug 2017 22:28:03 +0200, Richard Hipp <d...@sqlite.org> wrote:


On 8/23/17, j. van den hoff <veedeeh...@gmail.com> wrote:

On Wed, 23 Aug 2017 19:54:52 +0200, Richard Hipp <d...@sqlite.org> wrote:


unable to create directory /var


What happens when you try running this command on the latest trunk
check-in?


works again. no more hiccups. problem solved it seems. thanks a lot for
looking into this.



The problem is not yet completely solved.  It happened to fix your
case because the symbolic link is toward the beginning of the pathname
and the code now only checks the beginning of the path if the whole
path does not yet exist.

Removing support for --no-dir-symlinks will fix the problem.  But I
need to wait for feedback before backing out that feature.


understood. thanks.


--
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] strange problem with graphical diff

[j. van den hoff]

On Wed, 23 Aug 2017 19:54:52 +0200, Richard Hipp  wrote:


unable to create directory /var


What happens when you try running this command on the latest trunk  
check-in?


works again. no more hiccups. problem solved it seems. thanks a lot for  
looking into this.







--
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] strange problem with graphical diff

[j. van den hoff]

On Wed, 23 Aug 2017 18:09:56 +0200, Richard Hipp  wrote:

more important: is a fix/work-around possible (apart from telling me to  
do

it myself which I would have a hard time with ...)



Hold on there, honcho.  We are not your employees. This is a community
effort.  Expressing impatience with the debugging process is not an
effective strategy for recruiting volunteer helpers to work on the
problem.


I beg your pardon? you've got that completely wrong... by no means was  
this intended to signal/express impatience on my side. I am *not*  
impatient. and no need to explain the very obvious to me (regarding  
community effort and you not being my employees...), really. I appreciate  
the work invested into fossil as much as the next guy.


I was just asking whether a fix (or some user side work around I am not  
aware of) is possible/available. nothing more, ok? and the parenthesis  
just indicated that possibly proposing I contribute a patch would not be  
realistic due to lack of expertise on my side in C programming... that's  
all.  hope this is straightened out now..



--
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] strange problem with graphical diff

[j. van den hoff]

On Wed, 23 Aug 2017 17:14:05 +0200, Warren Young <war...@etr-usa.com>  
wrote:



On Aug 23, 2017, at 7:21 AM, Richard Hipp <d...@sqlite.org> wrote:


On 8/23/17, j. van den hoff <veedeeh...@gmail.com> wrote:

unable to create directory /var


It is trying to create a temporary file in which to store the one of
the two sides of the diff.  Can you trace the problem by running in a
debugger?


This sounds like a repeat of:

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24920.html

Basically, it’s an artifact of the way macOS symlinks /var, /tmp, etc.  
to their actual locations, which doesn’t happen on other *ix type  
systems, so the bug is never tickled there.


yes, this looks like the exact same problem, see my previous mail: fossil  
detects that `/var' exists while not being a directory and bails out  
(which it should not but rather resolve the link and check whether the  
resolved link is a directory...).


I reiterate that I wonder what has changed recently (either on the side of  
OSX or fossil) since the problem was definitely non-existent some time  
ago? and why does it work when omitting `--to' from the `gdiff' call? no  
idea...


more important: is a fix/work-around possible (apart from telling me to do  
it myself which I would have a hard time with ...)




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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] strange problem with graphical diff

[j. van den hoff]

On Wed, 23 Aug 2017 15:21:46 +0200, Richard Hipp <d...@sqlite.org> wrote:


On 8/23/17, j. van den hoff <veedeeh...@gmail.com> wrote:

unable to create directory /var



It is trying to create a temporary file in which to store the one of
the two sides of the diff.  Can you trace the problem by running in a


and it does that differently, depending on whether the `--to' option is  
explicitly specified (as indicated it does not work with the `--to' even  
if the flag is redundant and pointing to the CURRENT revision...)?



debugger?


not easily (OSX, clang rather than gcc etc.: don't even know whether gdb  
would work or which other debugger to use ...). so I have tried to trace  
it down the pedestrian way. result:


the error message is the one in line 650 of `file.c':

648 if( file_mkdir(zName, forceFlag) &&  
file_wd_isdir(zName)!=1 ){

649   if (errorReturn <= 0) {
650 fossil_fatal_recursive("unable to create directory  
%s", zName);

651   }
652   rc = errorReturn;
653   break;
654 }


file_mkdir returns -1, wd_isdir returns 2 and errno is 17 (file exists).  
this is of course true: under OSX `/var' is a link to `/private/var': so  
the file `/var' exists and it is not a directory (but rather is a link and  
points to one). so it seems that the test in `file.c' would have to  
account for the possibility that `/var' is a soft link pointing to some  
directory, no? simply skipping the whole block makes `gdiff' work again...


what I do not quite understand: I am sure that `gdiff' worked fine  
previously and that `/var' "always" was a soft link. so what has changed  
in `fossil' recently causing this (seeming) regression?


if I can provide further information, please let me know.

thank you

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

[fossil-users] strange problem with graphical diff

[j. van den hoff]

today I have stumbled over this problem:

issuing something like

fossil gdiff --from 823c95ff8a --to eac7dff4fe

yields the terminal output (in this example):

8<-

Index: Makefile
==
unable to create directory /var

8<-

and that's it the graphical diff program never pops up.

when omitting the `--to' everything works just fine.

don't know when it stopped working -- might not have used it for some time  
but it sure used to work. incidentally, in the above example `--to' is  
pointing to the CURRENT revision anyway so it should do exactly the same  
w/ and w/o the `--to' flag...


seen with

This is fossil version 2.3 [2a615bed11] 2017-07-31 17:42:57 UTC under  
macosx 10.12


am I missing something trivial?

thanks
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] Two easy questions

[j. van den hoff]

On Tue, 15 Aug 2017 19:57:34 +0200, Steve Schow  wrote:

Related to this question, anyone have any workflow suggestions for  
accomplishing this aside from remembering to bump the number manually in  
the file before every important checkin or commit?


my workaround is roughly like this:

put an invariant `include' directive into your source file where the  
included file (called, e.g., `version') is a) not tracked by fossil and b)  
contains the current hash as delivered by `fossil info'. under  
linux/unix/macosx I specifically use


fossil info|awk '/^checkout/{print substr($2,1,10)}'

to  get the hash itself.

I update the `version' file during the make run. personally, I am using  
this approach not so much with source code but mostly with LaTeX or  
AsciiDoc documents where I want the version info in the formatted (pdf or  
html) output. works just fine. (actually I also check that `fossil  
changes' does not report anything. otherwise I add a trailing `+' to the  
hash indicating that the document is currently not yet checked in). of  
course the temporary file (`version') might be avoided if instead of the  
`include' some sort of `exec' of a subprocess is available directly  
substituting the hash into a variable.


hth
joerg




On Aug 15, 2017, at 11:46 AM, Stephan Beal   
wrote:


1) no.


1 - Is there any way to embed a substitution parameter into a source  
file that Fossil can replace with version info at time of checkin?   
(similar to RCS).


thanks





--
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] Command-line output format

[j. van den hoff]

On Tue, 28 Mar 2017 09:16:33 +0200, Florian Balmer  
 wrote:



Citation from:

http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24841.html


... What can we do to help you move away from scripts that depend
on the details of command-line output and toward something that is
more likely to survive an update? ... Would it be better to run
SQL queries directly against the repository database? ... Are new
fixed-output-format commands needed in Fossil to extract
information that is important to scripts?


I'm working with a lot of scripts to process Fossil command-line output.

The JSON interface is not available with some of the precompiled
binaries I'm using, and parsing JSON from shell scripts or Windows
batch files seems not so trivial.

Running SQL queries directly would mean to reinvent the wheel and
perform complex operations in many cases, as i.e. the output of
`fossil whatis [check-in]` involves parsing and integrating all
amendments to a check-in (or thorough knowledge of the internal Fossil
storage format if this information is cached in some table).

Therefore, I would like to vote for the command-line output to remain
as stable as possible, make the suggested "fixed-output-format" the
default, and carefully document modifications to the command-line
output format in the Fossil change logs.


+1



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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[j. van den hoff]

On Sun, 26 Mar 2017 16:00:11 +0200, Scott Robison  
 wrote:



On Mar 26, 2017 7:13 AM, "Christophe Gouiran" 
wrote:

Hi all,

First of all many thanks for all your feedback.

I come back to you with an implemented solution.

After many thinking, for me not all commands need to send their outputs  
to

a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:


{snipped list of commands}

I appreciate what you're trying to do here, but what you've done (based  
on

your description) is create a maintenance nightmare (or headache at
minimum). Your implementation will forever need to be tweaked when new
commands are added or existing commands changed in some way that changes
their amount of output, perhaps based on some extra parameter. DRH
suggested that it should be based on any output, which would avoid the
worry about how fossil changes over time.

I'm coming around to the position that, given the ease of typing "|  
pager"

when desired, or defining an alias or using a wrapper of sorts, this
feature may be a mistake. I've never once wished that fossil had done  
this

for me, though I could be in the minority.


+1

--
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] No progress on "fossil cp"

[j. van den hoff]

On Mon, 16 May 2016 19:02:17 +0200, Warren Young  wrote:

1. f finfo can’t trace file history back through a rename.  The web  
version of this (f ui > Files > Ancestry) does manage to report the  
rename, but it doesn’t trace history back through that link to the old  
name.  Why would I want file history to cut off just because I renamed  
it?
2. If you attempt to merge a change between branches where one of the  
changed files was renamed after the branch point, Fossil will *silently*  
drop all changes to that file.  Then it will lie to you, telling you the  
merge was successful!  If the resulting partial merge compiles and runs,  
you might not immediately notice that you didn’t get 100% of the  
feature/fix.  (This happened to me just a week or two ago!)


I think I also ran into both of these problems and the second one,  
obviously, is really bad (and the first one bad enough: it's presence  
heavily discourages one (at least me...) from doing otherwise desirable  
tidyups...). I do hope there is a chance to see this fixed in future  
versions (considering there are users able to recognize a problem but not  
to fix it ;-))



--
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] Colored output on console

[j. van den hoff]

On Mon, 25 Apr 2016 18:03:27 +0200, Stephan Beal   
wrote:



On Mon, Apr 25, 2016 at 5:33 PM, Steve Schow  wrote:


On Apr 25, 2016, at 9:22 AM, Stephan Beal  wrote:

On Mon, Apr 25, 2016 at 4:48 PM, Michael Richter 
wrote:


http://fossil.0branch.com/fsl/wiki?name=Cookbook,


fwiw, i think you've misconstrued the conventional silence. i've always
intended it as, "whew! We dodged that bullet again!"

Stephan…I’m new here.  What do you mean by “dodged a bullet?  Is fsl
something to be afraid of for any reason?  I don’t want to waste my  
time if

so.  but I know I am going to  write my own wrapper scripts.  So I’m
genuinely interesting in anything that anyone else has done.



Let me back up and try to unmuddle the muddling i've done...

a) i'm _thrilled_ that Michael offers people a solution for this so that
they...


just for the record: `fsl' has been written by marc simpson (and he also  
still hosts the `fsl' repo). so (nearly or completely) all of the core  
functionality of `fsl' (as found on trunk) is due to him, I think. further  
tweaks/modifications can be found in some branches (one maintained by  
michael, another one by me...).




b) temporarily forget that fossil doesn't natively do it, until...

c) 4-6 months have passed and a newcomer, unaware of the fsl wrapper,
points out that fossil doesn't have this capability ;).

i personally have a strong allergy against platform-specific code  
(because
i code for coding's sake, and having to coddle various platforms takes  
the

fun out of it), and terminal output is one of those things which requires
platform-specific code. (Fossil has a good deal of code to ensure that
something as mundane as streaming console output behaves well in various
Windows environments.) But that's just my opinion, and those are very  
often

in the minority, so please don't take any of them too seriously.




--
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] Colored output on console

[j. van den hoff]

On Mon, 25 Apr 2016 16:48:43 +0200, Michael Richter   
wrote:


@michael: I have been using `fsl' myself happily for several years now. I  
also have tried a couple of times to draw attention to its existence on  
this list (getting the same feedback -- i.e.: none -- as you). but I am  
sure you are mistaken in your interpretation why this happens. why should  
anybody be hostile to you (or the tool)? I'm sure the lack of feedback has  
a much more profane reason: most people just don't care for any wrapper  
around fossil's CLI (or have their own) but are waiting for native support  
of the asked-for functionality or are much more interested in the web GUI.


@everybody: `fsl' indeed seems massively under-appreciated. it is very  
helpful and improves CLI interaction with fossil substantially in my  
experience (notably the branch where I have further adjusted everything to  
my own liking ("dresden") ;-)). colorized diff and timeline output and the  
alias facility alone are worth it (personally I wanted chronological  
"symbolic" checkin enumeration a la `hg' as well and got it in the  
above-mentioned branch ...).





I know that every time I mention this I get silently, perhaps even
hostilely, ignored, but really guys, why not just use fsl for your
customization needs?  Colourizing output is in the cookbook:
http://fossil.0branch.com/fsl/wiki?name=Cookbook, along with lots of  
other
nifty tricks like aliasing, adding commands (like workflow-based ones  
I've

done for my stuff), etc.  It really is a nifty little package and I don't
get the hostility (or at least utter apathy) it generates in the Fossil
community.

I look forward to the "ignore the very existence of this message" that is
traditional each time I bring it up.

On 25 April 2016 at 09:48, Steve Schow  wrote:


For now, if you’re on a unix platform, you can try a wrapper script like
this:



#!/bin/bash

export COLOR_NC='^[[0m'
export COLOR_RED='^[[1;31m’

fossil $* |\
sed -e "s/ERROR/${COLOR_RED}ERROR${COLOR_NC}/g” \
sed -e “s/WARNING/${COLOR_RED}WARNING${COLOR_NC}/g”







On Apr 24, 2016, at 4:07 AM, Marko Käning 
wrote:

> Hi devs,
>
> it would be great if one could colorise Fossil’s output on the  
console!

>
> Quite a few times I missed an error or warning message which slipped  
in

between of many lines of the usual fossil output on the console.
>
> Red colouring of words like “warning” or “error” would be very helpful
there.
>
> The poor man’s solution would at least be to use capital letters and
some sort of line head along the lines of
>
>   > ERROR: blaa
>   > WARNING: blubb
>
> Right now I can’t send an example of such a easily slipping through
message, but I can deliver if I come across one again.
>
> Greets,
> Marko
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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








--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] opening more than one ui on localhost

[j. van den hoff]

On Sun, 14 Feb 2016 13:10:49 +0100, Scott Robison  
<sc...@casaderobison.com> wrote:



On Sun, Feb 14, 2016 at 4:22 AM, j. van den hoff <veedeeh...@gmail.com>
wrote:


On Sun, 14 Feb 2016 02:12:01 +0100, Boruch Baum <boruch_b...@gmx.com>

wrote:



After Warren Young commented on the "flatness" of forum-style
discussions instead of the "threaded" viewing option in  
email-list-style

discussions, I realized that Wikipedia has had a solution that could be
easily implemented in Fossil projects without any software tweaking -
just create User:talk or Subject:talk pages, like Wikipedia has been

doing.



after following this thread loosely these last 1-2 days, just a short

comment: you are proposing a "solution" for exactly which "problem"? I
don't see any and would support the conservative approach here, i.e. "if  
it

ain't broken, don't fix it": email does the job just fine for the purpose
of this list in my view. I don't see _any_ problem, let alone one, that
switching to some sort of forum would fix (quite to the contrary,  
partly).

I believe the arguments have been all mentioned already, mainly by warren
young. so what exactly are your remaining gripes with just continuing to
use the present channel of communication (except that it seems somehow
(technically or otherwise) uncool to you ;-)) for discussions regarding
fossil (which is the only purpose of this list...)?


I was under the impression that it was more of a suggestion of something
the OP would like to use and less advocating for the fossil project to
embrace it.


OK, than I've got than wrong. sorry for the noise.



That being said, I can see certain benefits to keeping "all" that
information around in the project repository itself. From the fossil  
design

objectives:


Fossil should provide in-depth historical and status information about

the project through a web interface

{snip} Fossil attempts to better capture "collective intelligence" and

"the wisdom of crowds" {snip}

Also:


The global state of a fossil repository is kept simple so that it can

endure in useful form for decades or centuries. A fossil repository is
intended to be readable, searchable, and extensible by people not yet  
born.


of course all this seems to refer to the fact that one uses a revision  
control system and has access to the commit logs (timeline), rather than  
to putting lots of ephemeral stuff somehow into the repo as well, no?




There is a lot of intelligence that goes into mailing lists that might  
not

be captured in the repository without extra effort.


the question seems, whether this would be worth the effort and what could  
possibly be gained (in comparison to the present state: the project  
documents itself through (hopefully comprehensive) commit messages and its  
documentation and source code comments on the one side and there is a  
mailing list plus its archive to look for help/additional information on  
the other side).




Note that I'm not advocating for change, but part of me likes the idea.
More realistically there can be a lot of noise in forums and mailing  
lists


+1 (my last mail possibly being one example ;-))


and such that you wouldn't necessarily want to keep in the fossil record,
much more so than changes to code or documentation.


+1 again... there is such a thing as the signal to noise ratio which needs  
to be kept sufficiently high.


--
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] opening more than one ui on localhost

[j. van den hoff]

On Sun, 14 Feb 2016 02:12:01 +0100, Boruch Baum   
wrote:



After Warren Young commented on the "flatness" of forum-style
discussions instead of the "threaded" viewing option in email-list-style
discussions, I realized that Wikipedia has had a solution that could be
easily implemented in Fossil projects without any software tweaking -
just create User:talk or Subject:talk pages, like Wikipedia has been  
doing.


after following this thread loosely these last 1-2 days, just a short  
comment: you are proposing a "solution" for exactly which "problem"? I  
don't see any and would support the conservative approach here, i.e. "if  
it ain't broken, don't fix it": email does the job just fine for the  
purpose of this list in my view. I don't see _any_ problem, let alone one,  
that switching to some sort of forum would fix (quite to the contrary,  
partly). I believe the arguments have been all mentioned already, mainly  
by warren young. so what exactly are your remaining gripes with just  
continuing to use the present channel of communication (except that it  
seems somehow (technically or otherwise) uncool to you ;-)) for  
discussions regarding fossil (which is the only purpose of this list...)?


regards,
joerg




On 02/12/2016 06:59 PM, Barry Arthur wrote:
I was going to suggest an alternative approach being through  
enhancements

to chiselapp.com - but that is not any better than a mailing list if the
forum content is not stored inside the fossil repo for the associated
project, as was the desire of the OP, iiuc.

On the surface, it sounds appealing to have the project discussion  
stored

alongside the code in the same secure repository. That way a developer
cloning the repo would also have access to the discussion history too,  
with

the other obvious benefits as mentioned by the OP (understanding and
correct handling of artifact IDs, etc).

Non-developers cloning the repository might not appreciate having to
download years of project discussions, but:
* net is pretty fast these days and discussion would compress well in  
the

sqlite repo.
* PERHAPS the forum content could be optional when cloning

These concerns would be mitigated with the planned Fossil 2.0 feature of
allowing non-full repository clones.

As Warren says, contributing to the forum would require authentication.
Frustrating, but sadly a necessity.

Not having to hunt down and possibly register for a project's discussion
system -- it's built-in when you clone. Ok, for the authentication need
you'd still need some form of registration, but I haven't thought enough
about that (OpenID?). Not all projects use simple mailing lists and as
Warren pointed out in several posts recently, there are many flashy  
options
projects could choose from, each requiring their own unique log-in and  
user

interface and usage philosophy (mailing list vs forum, for example).

Given that Richard has expressed an interest in building his own email
server, maybe the chances of bundling a project's forum within its  
fossil

repository in the future exceed zero. :-)


On 13 February 2016 at 04:54, Warren Young  wrote:


On Feb 12, 2016, at 2:11 PM, Yannick Duchêne 
wrote:


On Fri, 12 Feb 2016 11:24:05 -0700
Warren Young  wrote:

On Feb 12, 2016, at 10:33 AM, Boruch Baum   
wrote:

Email has its problems, but there’s an awful lot of antispam

infrastructure around it that would have to be recreated to allow
fossil-scm.org (or sqlite.org) to self-host a web forum with equivalent
protections.


But the issue from a user point of view, is near the same: you  
receive a

lot of email on a mailing list

This list averages about 10 messages a day, and that’s including the
occasional flame-fest, which you can entirely ignore if you like.

That’s “a lot”?


while on a forum, you just follow some threads


I see that you’re using Claws Mail.  From its features page: "'Ignore
thread’ option”, and "Watch marked threads”.  Thunderbird and other  
mailers

have such features, too.

Those features aren’t universal, but simply having a thread-aware  
mailer
makes ignoring unwanted threads straightforward.  Just skip over  
threads

whose title is uninteresting.

The other key email management practice is filtering messages into
per-list folders, so you can choose where in your day you wish to spend
time looking at the mailing list for each particular project.  Every
mailing list manager includes at least one tag in the email to make  
such

filtering easy.

In this case, there are at least three such tags:

  Subject: [fossil-users]…
  To: fossil-users@…
  List-Id: Fossil SCM user's discussion…


opting-out means receiving nothing at all any‑more


Mailers with thread-kill features still download all the list traffic.
They just send it to the bit bucket or otherwise hide it.

Once upon a time, people complained about the ISP costs associated with
downloading 

Re: [fossil-users] fossil sync doesn't sync

[j. van den hoff]

On Wed, 02 Dec 2015 16:56:35 +0100, Andy Gibbs   
wrote:



I upgraded after the problem occurred.  I was running 1.32 on the server
and 1.32 or 1.33 on the clients.  All are running 1.34 now.


which at least means they were all post 1.30 (in which version the sync  
bug presumably was fixed) so I would take this as a strong indication that  
there still is a problem, right?


--
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 sync doesn't sync

[j. van den hoff]

On Wed, 02 Dec 2015 08:44:42 +0100, Andy Gibbs   
wrote:



 Next time this happens, try running:
fossil sync --verily



question: as per changelog of version 1.30 the sync protocol bug causing  
the hiccup was fixed for that release? does this mean the `--verily' flag  
is obsolete these days? because, for one it is not (or no longer?)  
documented in `fossil help sync' and second, it still is an accepted  
option of `fossil sync'. what is the exact state of affairs in these  
matters?


thank you

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

[fossil-users] missing quotes around wiki page name on the 'whistory?name=' page

[j. van den hoff]

contrary to the `/info/artifact_id' page, where the headline reads

project name / Update of "name_of_wiki_page"

including explicit double quoting of the name of the wiki page, on the  
`/whistory/?name=' page it instead reads


project name / History of name_of_wiki_page

which, depending on the title of the wiki_page, can be somewhat  
misleading. I think the wiki page name should be quoted here as well.



thank you

joerg

ps: this is with the default skin (if it is a skin specific issue)

--
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 sync doesn't sync

[j. van den hoff]

On Wed, 02 Dec 2015 13:01:42 +0100, Richard Hipp <d...@sqlite.org> wrote:


On 12/2/15, j. van den hoff <veedeeh...@gmail.com> wrote:

what harm (in times of sync time/network traffic) would it do to
make `--verily' the default action of sync?



On the Fossil self-hosting repository, "fossil sync" takes 0.535s and
uses 2,961 bytes of network traffic.  But "fossil sync --verily" takes
4.783s and uses 1,580,941 bytes of network traffic.


I see... but still: do we have again a recognized sync bug since  
yesterday? if so, how relevant do you consider it? I'd like to understand  
the situation a bit better...








--
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 sync doesn't sync

[j. van den hoff]

On Wed, 02 Dec 2015 11:54:06 +0100, Richard Hipp <d...@sqlite.org> wrote:


On 12/2/15, j. van den hoff <veedeeh...@gmail.com> wrote:


thank you. sorry if this has been discussed/explained before: this  
means,

there still is demand for that option? why? is there still a bug out
there? because if not, it seems whatever `--verily' is doing here should
be done all the time in order to avoid incomplete syncs in the first  
place?




There are no known bugs.  --verily is a defensive measure in case some
currently unknown bugs appear in the future.


well, the OP reporting the sync failure yesterday (andy gibbs) stated:

"I am syncing with a single server, and I have made sure all the clients  
have

the same fossil version as the server (actually I've upgraded them all to
the latest released version). ..."

so, if this is correct, the phenomenon -- and thus a bug known since  
yesterday -- seems to persist in 1.34 or is this an invalid conclusion? of  
course, it's good to know that `--verily' fixes it but it seems a quite  
unfortunate situation that complete sync is not guaranteed without that  
option. what harm (in times of sync time/network traffic) would it do to  
make `--verily' the default action of sync?





--
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] problems with links in embedded documents

[j. van den hoff]

On Mon, 23 Nov 2015 20:19:28 +0100, Richard Hipp  wrote:


That's all well and good, but Joerg is right - it would be convenient
to be able to specify the root of the repository in a hyperlink.  I've
pondered making that possible with some bit of magic like
"[$ROOT/wcontent]" or "".  But it seems
hackish.


could you elaborate on that? it's not currently an option to do something  
like that, right? if it would be implemented I would think this to be  
rather more natural than the currently necessary `../../../wcontent' when  
linking from some embedded doc in `repo-root/www' which requires knowledge  
of the `/doc/trunk' "mount point" as well in order to get it right.



--
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] problems with links in embedded documents

[j. van den hoff]

On Mon, 23 Nov 2015 20:13:40 +0100, Warren Young <w...@etr-usa.com> wrote:

On Nov 23, 2015, at 9:42 AM, j. van den hoff <veedeeh...@gmail.com>  
wrote:


You could still serve multiple Fossil repositories via your web  
server’s name-based virtual hosting feature


I will have to look into this, thank you for this tip.


I was curious, so I looked into it.  The Fossil docs only talk about  
nginx, but I’m more familiar with name-based virtual hosting on Apache,  
so I worked out how to configure it:


NameVirtualHost prj1.yourcompany.private:80

ServerAdmin webmaster@yourcompany.private
ServerName prj1
ServerAlias prj1
ProxyPass / scgi://localhost:4000/
SetEnvIf Request_URI . proxy-scgi-pathinfo


Then, set up the back-end server via:

$ fossil server /path/to/prj1.fossil --scgi --localhost --port 4000 &

Having done this, visiting http://prj1 will transparently show the  
Fossil UI for prj1.fossil.


The point of this scheme is that you can run one fossil instance for  
each repository you want to serve, using a different SCGI port number  
for each, mapping each SCGI port to an alias on your web server.  Each  
of those name-based virtual hosts will present the corresponding Fossil  
UI at the root of the URL hierarchy, so you won’t run into local/remote  
discrepancies like the one you found.


will put this on the "things to investigate stack", thank you.

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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] problems with links in embedded documents

[j. van den hoff]

On Mon, 23 Nov 2015 16:10:02 +0100, Warren Young <w...@etr-usa.com> wrote:

On Nov 22, 2015, at 6:47 AM, j. van den hoff <veedeeh...@gmail.com>  
wrote:


my (obviously
wrong/incomplete understanding so far is that `/wcontent' is an absolute
path relative to the repository root…


I think the problem is that you’re serving a collection of Fossils,  
instead of just one.


yes, that's quite probably true, but I'm not sure whether its a "natural"
problem or might be something calling for a fix...



I don’t use the CGI model, but with “fossil server /path/to/one.fossil”  
the URLs are of the form http://server.ip:port/wcontent.


The difference with the “local” case is that “fossil ui” is only serving  
a single Fossil repo.


So, bottom line, you need to either use relative URLs, or remove this  
confounding difference between the local and CGI cases, serving only one  
repo per Fossil server.


this is not really an option, at least not desirable: its much easier to  
administrate when putting all the repositories into a common directory  
following the procedure recommended for that in the Fossil documentation.


I still wonder, whether the observed behavior is to be expected and/or  
unavoidable in my setup, maybe you or someone else could help me  
understand the situation further/better:


* is it "obvious" that `/wcontent' will point to  
`https://server.domain/wcontent' for a cgi-served repo?
  ** if so could this not be changed, since one ends up with the link  
`/wcontent' working correctly locally (in the clone) but not on the server


* what causes the weird "redirection" I see when using something like  
`/wcontent' as a link, namely the switch to a different repo residing in  
the same cgi-served directory on the server?




You could still serve multiple Fossil repositories via your web server’s  
name-based virtual hosting feature, so that  
http://prj1.mycompany.private maps to prj1.fossil, and so on for prj2,  
etc.


I will have to look into this, thank you for this tip.




hitting the
`/wcontent' link on the server GUI does not simply just not work with
error 404 or something like that but rather navigates to the home page  
of
another unrelated fossil cgi repository residing in the same directory  
on

the server. what's going on here?


That sounds like a CGI-specific behavior.  We use “fossil server  
/museum” (where /museum is where the Fossils live) here, and  
http://server:port/wcontent *does* give a 404.

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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] typo in admin_sql wiki page

[j. van den hoff]

someone with write access to the fossil repo might do a minor good deed  
;-):


In the sentence

"Only *a* the first statement in the entry box will be run."

the `a' enclosed in the asterisks should go away (Fossil version  
[63256980ee])


--
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] problems with links in embedded documents

[j. van den hoff]

On Mon, 23 Nov 2015 22:04:07 +0100, Richard Hipp <d...@sqlite.org> wrote:


On 11/23/15, j. van den hoff <veedeeh...@gmail.com> wrote:

On Mon, 23 Nov 2015 20:19:28 +0100, Richard Hipp <d...@sqlite.org> wrote:


That's all well and good, but Joerg is right - it would be convenient
to be able to specify the root of the repository in a hyperlink.  I've
pondered making that possible with some bit of magic like
"[$ROOT/wcontent]" or "".  But it seems
hackish.


could you elaborate on that? it's not currently an option to do  
something

like that, right? if it would be implemented I would think this to be
rather more natural than the currently necessary `../../../wcontent'  
when
linking from some embedded doc in `repo-root/www' which requires  
knowledge


of the `/doc/trunk' "mount point" as well in order to get it right.



What should the magic symbol be?  Some ideas:

FOSSIL_ROOT
$
THIS
THIS_REPO


from these, I would choose FOSSIL_ROOT. spontaneous idea: would a single  
slash be out of the question, so that the link relative to repo-root would  
read


//wcontent


or similar?





--
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] problems with links in embedded documents

[j. van den hoff]

I am currently giving embedded docs and the wiki another try (never had
much need for it till now) and am having some difficulties regarding
cross-linking between an embedded doc and any of the default wiki pages,
e.g. `wcontent' in a way that it works on a cgi-served repo and its local
clone. consider the document to reside in, say, `path-to-repo/www/doc.md'.

what I then see is:

in local clone:

link   expands to
   ==

../../../wcontent  http://localhost/wcontent  (OK)

/wcontent  http://localhost/wcontent  (OK)

wcontent  http://localhost/doc/trunk/www/wcontent  (not OK)

the same links expand in the cgi-served repo's GUI as

link   expands to
   ==

../../../wcontent
https://server.domain/repo.cgi/project-name/wcontent  (OK)

/wcontent  https://server.domain/wcontent  (not OK)

wcontent
https://server.domain/repo.cgi/doc/trunk/www/wcontent (not OK)


while I _do_ understand that the last variant (purely relative identifier
`wcontent') does not work and is interpreted the way it is, i.e. as
pointing to a non-existing page (or rather file) in the `www' directory',
I'm at a loss regarding
`/wcontent'.

I would have thought that `/wcontent' would work locally (as it actually
does) as well as on the server (which it does not). my (obviously
wrong/incomplete understanding so far is that `/wcontent' is an absolute
path relative to the repository root...

what is even more confusing and somewhat alarming is that hitting the
`/wcontent' link on the server GUI does not simply just not work with
error 404 or something like that but rather navigates to the home page of
another unrelated fossil cgi repository residing in the same directory on
the server. what's going on here?

any help in understanding this would be appreciated.

thanks,

joerg

ps: if it matters: this is with fossil 1.34 ([63256980ee]) on the server
and 1.33 (18fc492a95) on the local machine

--
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] diff after update

[j. van den hoff]

On Sat, 12 Sep 2015 01:45:28 +0200, Johan Kuuse  wrote:


fossil diff -before

or

fossil diff -before-commit


typo... I just wanted to propose another name for the requested option,  
and actually I meant "call it `diff --before' or `diff --before-update'  
which I for one would be able to memorize as "compute diff of current  
state vs. state before the preceding update". actually, considering the  
original posters `subject' line, one might also look at it the other way  
round and call it `diff --after-update' ;-)


personally, I find reference to the undo buffer a long way from being  
obvious to someone just using fossil as DVCS (rather than someone  
interested in in the details/internals of `fossil').




?
El 12/9/2015 1:14, "Andy Bradford"  escribió:


Thus said Richard Hipp on Fri, 11 Sep 2015 10:11:30 -0400:

> "fossil diff --versus-undo" maybe???

What if instead of making this a  feature of ``fossil diff'' it became a
feature of ``fossil undo?''

fossil undo --diff

Andy
--
TAI64 timestamp: 400055f36093
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] diff after update

[j. van den hoff]

diff --before(-update)

On Fri, 11 Sep 2015 20:20:53 +0200, Warren Young  wrote:


On Sep 11, 2015, at 11:41 AM, Ron W  wrote:


On Fri, Sep 11, 2015 at 1:12 PM, Warren Young  wrote:

Though --from-undo is better in that it tells you what the option does,  
you have to know that Fossil has an undo buffer to make sense of it.   
That’s exposing internal implementation details in the UI.


I disagree. The "fossil undo" command already tells you Fossil has an  
undo buffer,


No, the undo command just tells you that Fossil has some unspecified way  
to achieve an undo.  It doesn’t tell you how it accomplishes that.


I don’t want Fossil users to be required to think about how undo is  
implemented when they ask Fossil, “What just happened?”



How does “fossil diff --last” strike you?

I think "--last" would be interpreted as a short cut for "--to latest”


No, latest is “now.”  “Last” is “then”.  (“When will now, be then?”   
“Soon.”)


If it’s the “L” that’s hanging you up, there are synonyms.  --prior and  
--prev come to mind.

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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why Hash

[j. van den hoff]

On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal <sgb...@googlemail.com>  
wrote:



On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein <bmburst...@gmail.com>
wrote:


On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
veedeeh...@googlemail.com> wrote:


in a breach of promise to myself to never again argue in favour of this
functionality on the fossil mailing list (it came up a few times over  
the

last years):


If I understand correctly, the way fossil is designed could cause the
numbers to change *even locally* upon a rebuild, or even just a sync.  
This

would probably get confusing.



Correct. And if i'm not mistaken, if you rebuild with the --randomize
option then the order could get even weirder.


well, I'm only talking about the ordinal numbers chronologically  
enumerating the timeline checkin(!) entries. this enumeration will not  
change as a consequence of rebuild, right? it might change after a sync  
against some remote repo if there are incoming checkins chronologically  
interleaved with my own, sure, but so what? the relative numbers would be  
just a (somewhat "volatile") convenience measure _locally_. and I agree  
with another recent post that this would primarily concern the CLI. what I  
mean: go ask some hg users when they last did use sha1 hashes for  
specifying checkins in their interaction with hg (which supports both the  
ordinals as well as the hashes for doing so) and how often the presence of  
those numbers confused communication with other developers in their  
project. I'm quite sure they _never_ specify sha1 hashes to denote  
checkins in any small to medium-sized project  below 10^4 checkins  
(currently
this still includes fossil itself). not so sure about the "communication"  
issue if users forget the potentially 'volatile' nature of the relative  
enumeration, but this just can't possibly be a big issue ...


I therefore just maintain it would be "nice to have". it sure ain't a  
killer feature, I admit ...




(@Joerg: i was trying to remember who it was who used to ask for this
feature ;)


I plead guilty ;-). and will now keep quite again regarding this issue 






--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why Hash

[j. van den hoff]

On Thu, 10 Sep 2015 16:54:30 +0200, Martin Gagnon <eme...@gmail.com> wrote:


On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote:

On 10 September 2015 at 15:17, j. van den hoff
<veedeeh...@googlemail.com> wrote:
> On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal  
<sgb...@googlemail.com>

> wrote:
>
>> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein  
<bmburst...@gmail.com>

>> wrote:
>>
>>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
>>> veedeeh...@googlemail.com> wrote:
>>>
>>>> in a breach of promise to myself to never again argue in favour of  
this
>>>> functionality on the fossil mailing list (it came up a few times  
over

>>>> the
>>>> last years):
>>>
>>>
>>> If I understand correctly, the way fossil is designed could cause  
the
>>> numbers to change *even locally* upon a rebuild, or even just a  
sync.

>>> This
>>> would probably get confusing.
>>>
>>
>> Correct. And if i'm not mistaken, if you rebuild with the --randomize
>> option then the order could get even weirder.
>
>
> well, I'm only talking about the ordinal numbers chronologically  
enumerating

> the timeline checkin(!) entries. this enumeration will not change as a
> consequence of rebuild, right? it might change after a sync against  
some
> remote repo if there are incoming checkins chronologically  
interleaved with
> my own, sure, but so what? the relative numbers would be just a  
(somewhat
> "volatile") convenience measure _locally_. and I agree with another  
recent
> post that this would primarily concern the CLI. what I mean: go ask  
some hg
> users when they last did use sha1 hashes for specifying checkins in  
their
> interaction with hg (which supports both the ordinals as well as the  
hashes

> for doing so) and how often the presence of those numbers confused
> communication with other developers in their project. I'm quite sure  
they
> _never_ specify sha1 hashes to denote checkins in any small to  
medium-sized

> project  below 10^4 checkins (currently
> this still includes fossil itself). not so sure about the  
"communication"
> issue if users forget the potentially 'volatile' nature of the  
relative

> enumeration, but this just can't possibly be a big issue ...
>
> I therefore just maintain it would be "nice to have". it sure ain't a  
killer

> feature, I admit ...
>

Given that fossil does not support history rewriting by design the
commit number on a particular branch counting from root is unique and
stable per branch across all repos.

If you release from a single master branch you have a monotonous
snapshot number.

When you use multiple branches you need to add branch name to have
stable unique identifier.

This is not viable eg. for git with rebasing.


Even in fossil it could be a problem, it cannot re-write history but a
branch is just a tag that can change. The identifier will change
after moving checkins on a branch.


is it not much simpler? the timeline of all checkins in any given checkout  
has a well-defined immutable chronological order (as displayed by `fossil  
timeline -t ci': and since fossil knows this order it could easily  
enumerate the checkins just fine...). just enumerating them from "old to  
new" yields the rank/ordinal/sequential number we are talking about that  
might serve as replacement of the hashes for any fossil command where  
those need to be specified. the enumeration just is not unique across  
clones not being completely in sync/identical. but the mapping of these  
numbers to sha1 hashes in _my_ clone (i.e. the sequence of checkins  
displayed in the timeline) of the project might only change (as far as I  
can see) if a sync injects "remote" checkins into the timeline that are  
interleaved with my own (instead of just being "newer" than any of mine).  
that's all. so the mapping `rank <--> sha1' indeed can change (that's why  
the rank cannot completely replace the hashes for uniquely identifying a  
checkin) due to this "chronological interleaving" of checkins in different  
clones of the project. but that's all (the mapping would even be identical  
across all clones being completely in sync at the considered point in  
time). and it really is just irrelevant for the simple envisaged  
convenience measure: being able to use the ranks instead of the hashes for  
identifying checkins in _my_ clone when interacting with fossil. but if  
implementing this seems not worth the effort to the devs, so be it.









--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why Hash

[j. van den hoff]

On Thu, 10 Sep 2015 20:16:52 +0200, Martin Gagnon <eme...@gmail.com> wrote:


On Thu, Sep 10, 2015 at 08:39:49PM +0300, Baruch Burstein wrote:

   On Thu, Sep 10, 2015 at 8:03 PM, j. van den hoff
   <[1]veedeeh...@googlemail.com> wrote:

 and it really is just irrelevant for the simple envisaged  
convenience

 measure: being able to use the ranks instead of the hashes for
 identifying checkins in _my_ clone when interacting with fossil.

   I am starting to agree. When I used hg, I didn't usually even  
remember the

   local numbers. I would usually look them up in the timeline of recent
   checkins, and then use them for diffs/branches/rollbacks/whatnot. It  
was

   just easier than hashes. So the renumbering would not be critical.


I agree, but the only *potential* problem would be when people blindly
use the sequential number when posting links on mailing list or forum.
It  could become confusing when the link point to another valid link,
but not the good one.


yes, beyond "checkin 1000" this could happen (if by chance there is some  
checkin whose sha1 hash starts with those 4 digits). but I would argue  
that when posting links or talking about checkins on mailing lists it  
simply should be considered mandatory to use the hashes. should not be  
_that_ much of a pedagogical challenge to drive that point home ;-)







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why Hash

[j. van den hoff]

On Wed, 09 Sep 2015 20:19:04 +0200, Ron W  wrote:

On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari   
wrote:


Some DVCS, like hg, use both an hash and a sequential number.



As I recall (been a few years since I last used hg), the numbers were
"relative" to the output of hg's equivalent to "timeline".

Assuming I am remembering correctly, if Fossil had this feature, you  
could

do something like:

$ fossil timeline -N -n 3
0  [d28be5063a] *CURRENT* Fix linker parameter file
1  [10a5af61c1] Alt code for HS interface
2  [5250e3796e] Increase speed threshold
$ fossil info 1
uuid: 10a5af61c1fc25060ad428de9c82e3615b45f6c8 ...

The numbers, of course, could change after any sync or commit.


in a breach of promise to myself to never again argue in favour of this  
functionality on the fossil mailing list (it came up a few times over the  
last years):


having simple chronological checkin numbers as an alternative way of  
specifying checkins _locally_ just the way hg  has done for years would be  
a *good* thing. simply because for most projects (all the small ones out  
there) specifying chronological numbers is shorter/easier than specifying  
(unique min 4-digits prefixes of) sha1 hashes. and the "chronologic  
property" itself is helpful in itself, e.g in comparing 'current vs.  
previous' checkin. and until checkin  its at least break even in terms  
of typing effort. the fact that those chronological checkin numbers are a  
local property of each clone/checkout rather than of the repo proper is  
beside the point in my view: it is true but mostly irrelevant. I concede  
that there might arise confusion if people are really not aware of the  
potential ambiguity of those chronological numbers across different clones  
if they start to argue about a certain checkin. but when interacting with  
fossil it cannot have adverse effects afaiks. rather the opposite.




--
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] Search feature

[j. van den hoff]

On Mon, 17 Aug 2015 18:04:37 +0200, sky5w...@gmail.com wrote:


​I read the search feature is in a trial stage.
Can it be expanded to search in actual source files?
Now using the browser and only per file. Or of course in an external tool
in my checkout folder.

Thanks for Fossil.


until the time comes where fossil supports grep out of the box I'm using  
the following qd shell script. provided you are on linux/unix/macosx this  
should
work for you (N.B.: I'm using `ksh' rather than `bash' (or `zsh'). to make  
it work with `bash' you'd need to replace the `print' command by `echo' or  
a suitable `printf' call (and find out what the equivalent of `print -r  
--' in bash is ... probably some similar `printf' construct). in any case  
you get the idea
sure it is inefficient (dumps all revisions of the file and greps through  
all of them ...), but it works OK for me.


8--

#!/usr/bin/env ksh
#--
# purpose: grep through all revisions of one or more files from a `fossil'
# repository.
#
# calling syntax:
#
#fslgrep grep-options pattern file {file ...}
#
# where `grep-options' is passed to `grep'. options taking arguments for  
the

# time being must *not* contain spaces (or the whole option string must
# be enclosed in quotes).
#
# example:
#
# fslgrep '-C 5' foo bar.txt
#
# will look for `foo' in all revisions of `bar.txt' and report them with a  
5 line context.


#--
function getHashes { # `fossil finfo -W 0' output
   print $1 | awk '
  NR == 1 {next}
  /^[0-9]/ {
 sha1 = substr($2, 2, length($2) - 2)
 print sha1
  }
   '
}
#--
# define default grep options to be used:
options=--colour=always 

# append user defined options and extract grep search pattern
for i do
   [[ $i == -* ]]  {
  options+=$i 
  ((optcnt++))
   }
done
((optcnt  0))  shift $optcnt
pattern=$1
shift

for i do
   timeline=$(fossil finfo -W 0 $i)
   (($? == 0)) || continue
   hashes=$(getHashes $timeline)

   for h in $hashes; do
  rep=$(fossil cat -r $h $i | cat -n | grep $options $pattern)
  (($? == 0))   {
 print -- \n** $i [$h] **
 print -r -- $rep
  }
   done
done

8--

HTH

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] Automatically put version / checkout infomation into source code on commit

[j. van den hoff]

On Tue, 14 Jul 2015 07:05:05 +0200, Christopher M. Fuhrman  
cfuhr...@pobox.com wrote:



On Mon, 13 Jul 2015 at 9:50pm, Christopher M. Fuhrman wrote:



Although now that I think about it, using info here is slower than
using status, so I may change that.


Ah, I stand corrected:

[ cmf-bigMac-09:56 PM ]-pkgsrc $ time fl info
project-name: NetBSD pkgsrc
repository:   /Users/cfuhrman/repos/pkgsrc.fossil
local-root:   /Users/cfuhrman/Documents/dev/pkgsrc/
config-db:/Users/cfuhrman/.fossil
project-code: a93518a42fa8e06695943fd79049ad4fcf8b9d00
checkout: 1d48efddf0177e14b213ccf27360e783775f7c0a 2015-07-13
09:54:20 UTC
parent:   ffe1ad6243d489148705a468bc4a19c131b13c32 2015-07-13
09:53:55 UTC
tags: trunk
comment:  Adapt for p5-pcsc name change. Bump PKGREVISION. (user:
wiz)
check-ins:789466

real0m0.213s
user0m0.080s
sys 0m0.125s
[ cmf-bigMac-09:57 PM ]-pkgsrc $ time fl status
repository:   /Users/cfuhrman/repos/pkgsrc.fossil
local-root:   /Users/cfuhrman/Documents/dev/pkgsrc/
config-db:/Users/cfuhrman/.fossil
checkout: 1d48efddf0177e14b213ccf27360e783775f7c0a 2015-07-13
09:54:20 UTC
parent:   ffe1ad6243d489148705a468bc4a19c131b13c32 2015-07-13
09:53:55 UTC
tags: trunk
comment:  Adapt for p5-pcsc name change. Bump PKGREVISION. (user:
wiz)

real0m1.308s
user0m0.291s
sys 0m0.919s

info is faster than status!



incidentally I'm using nearly exactly the same approach including the call  
to `status' (as I was under the same misconception that it should be the  
most efficient way to get at the sha1 hash). so I have just switched to  
`info' as well. but calling `status' two times in a row, one sees that the  
second call is much faster, so I presume `status' is reading a lot of  
stuff which then is cached. since the information displayed by `info' and  
`status' seems virtually identical: what is the reason for the high  
latency of a first `status' call?




Cheers!






--
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] Automatically put version / checkout infomation into source code on commit

[j. van den hoff]

On Tue, 14 Jul 2015 06:50:57 +0200, Christopher M. Fuhrman  
cfuhr...@pobox.com wrote:



On Mon, 13 Jul 2015 at 4:17am, Michael Weise wrote:



Thanks for all the answers,

I wrote my own little script that extracts the output of
'fossil status' with the help of sed and writes it to a file.
It's invoked as part of the build process:

fossil status | sed -n 's/checkout: *\([a-zA-Z0-9]*\) \(.*\)/#ifndef
CHECKOUTVERSION\n#define CHECKOUTVERSION\n#define
CHECKOUT_VERSION_STRING \1\n#define CHECKOUT_TIMESTAMP_STRING
\2\n#endif/p'  ../checkoutVersion.h


Here's how I do it in my GNUmakefile/Makefile:

--begin snippet--
version: VERSION

VERSION:
	@fossil info | grep ^checkout | awk '{ printf [%s] %s %s,  
substr($$2, 0, 10), $$3, $$4 }'  VERSION

--end snippet--

Although now that I think about it, using info here is slower than
using status, so I may change that.


not that it matters but you could avoid calling grep, of course (and  
substrings are not zero-offset in awk...):


fossil info|awk '/^checkout/ {print substr($2,1,10)}'

;-)


Cheers!




What's the advantage of using a manifest file?

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






--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Code beauty

[j. van den hoff]

On Fri, 19 Jun 2015 16:40:51 +0200, Stephan Beal sgb...@googlemail.com  
wrote:


On Fri, Jun 19, 2015 at 4:37 PM, Andy Gibbs andyg1...@hotmail.co.uk  
wrote:



I expect it was simply over-looked during import from a 3rd-party.



Yes:

https://github.com/antirez/linenoise/blob/master/linenoise.c



I for one don't take offense in reading line 216 (it caused a slight smile  
only) and would not send an Orwellian thought police squad to rewrite  
history (which would be anathema to fossil anyway), really. no offense  
meant, I'd say, by the linenoise author (nor by me in writing this ;-)).


j.


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] `fossil set mv-rm-files' throws error no such setting: mv-rm-files in 1.33 [18fc492a95]

[j. van den hoff]

On Sat, 13 Jun 2015 13:43:30 +0200, Martin Gagnon eme...@gmail.com wrote:


./configure --with-legacy-mv-rm


indeed, that works, thanks a lot!

I still have some difficulties in understanding the why (if not how,  
anymore ...) of this:


* so, without that configure flag, `fossil set' does not know about the  
setting, but `fossil help set' and `fossil help mv' talk about it.
question: why is it not available by default in view of the fact that the  
default behaviour (off) means the old behaviour of not touching the  
checkout during `mv' is preserved anyway, which, I understand, is deemed  
desirable (personally, I would argue for changing this at some point)?


* the wording in `fossil help set' seems confusing to me: compiled with  
legacy mv/rm support to me sounds like restore the old behaviour which  
otherwise is different now. but it seems the other way around, mostly.  
(and if the necessity to compile with legacy support is mentioned in  
`fossil help set' it might as well provide a hint to use the  
`--with-legacy-mv-rm' configure flag.)


not really an issue, but still ...

thx/j

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] `fossil set mv-rm-files' throws error no such setting: mv-rm-files in 1.33 [18fc492a95]

[j. van den hoff]

the new `mv-rm-files' setting is not working for me as per subject of this  
mail. what am I missing? do I need to use some compile time flag (wouldn't  
think so ...)?


thx/j

ps: if it matters, I see this on a macosx machine.

--
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] trunk closed??

[j. van den hoff]

On Fri, 29 May 2015 17:38:39 +0200, Richard Hipp d...@sqlite.org wrote:


On 5/29/15, Matt Welland mattrwell...@gmail.com wrote:
This is an exceedingly confusing behavior from fossil but the fix is  
easy.

Just do fossil up trunk.



Indeed - Fossil is doing exactly the right thing here.  If you just
fossil update it advances you to the tip of whatever branch your are
currently on.  If you want to be at the tip of trunk, you really do
need to say fossil update trunk.

We emphatically do NOT want Fossil second-guessing what branch you
want to be on when you do fossil update without an argument.



for sure not. OTOH: although it has not (yet) happened to me, I can easily  
see that it is confusing to leave trunk if I *am* on trunk before the  
update and just issue `fossil up' (which most of the time for most of the  
users seems to mean move me forward on this branch (especially trunk) to  
the current, last version of this branch rather than move me to  
wherever my current checkout has evolved. at least that would be me  
guess...). so while fossil should not second-guess my intention and  
implement it, it very well _might_ second-guess my intention and notify me  
when I am probably doing something unintentional.


as with assorted other things (e.g. empty checkin messages), should fossil  
not ask at this point (with a default of staying on the current branch)?  
the scenario would be


* I am on branch X
* I issue `fossil up' w/o argument
* `fossil' notes that this will move me to a different branch since  
someone else has transplanted the last checkin to a different branch

* fossil asks if I do want to proceed or simply stay where I am.

it should happen seldom enough in order not to annoy anybody if such a  
question is issued.


thx/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] how to move commits to a different branch

[j. van den hoff]

On Thu, 28 May 2015 23:29:14 +0200, j. van den hoff  
veedeeh...@googlemail.com wrote:



On Thu, 28 May 2015 23:14:30 +0200, Ron W ronw.m...@gmail.com wrote:

On Thu, May 28, 2015 at 5:09 PM, j. van den hoff  
veedeeh...@googlemail.com

wrote:


On Thu, 28 May 2015 22:47:32 +0200, Ron W ronw.m...@gmail.com wrote:



graft ?



used by mercurial for our `merge --cherrypick'. I believe it is  
desirable
to avoid as far as possible names clashes where the functionality  
behind

the command is completely different since it complicates both migration
between different systems as well as concurrent usage in my view. dito  
for

`transplant'.



splice ?


wouldn't be a good visulisation of what is going on in my  
understanding or rather, the emphasis here seems to be on cut and  
paste rather than paste alone.




(FWIW, graft seems a weird verb to use in the context of merging. But  
I

can see you point.)


depends on the POV, I'd say. if you sink of a single checkin as a sort


OMG... think, not sink. despite me being from germany.

of sprout on the branch it seems quite OK. actually, I find it  
slightly more difficult to view a cherrypick of a single changeset as a  
special case of merge (even when ignoring the fact that it is not at all  
visualized as a merge in the timeline anyway). so graft would seem OK  
with me for that action in `hg'. as it would be for retagging a branch  
in `fossil' (actually my preferred choice...) were it not already used.






--
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] how to move commits to a different branch

[j. van den hoff]

On Thu, 28 May 2015 22:21:19 +0200, Ron W ronw.m...@gmail.com wrote:


On Thu, May 28, 2015 at 2:56 PM, Andy Bradford amb-fos...@bradfords.org
wrote:



So perhaps something similar like:

fossil branch mv BRANCH-NAME BASIS



I think fossil branch mv BASIS BRANCH-NAME is more intuitive (also
consistent with fossil mv OLDNAME NEWNAME)


+1

and maybe another keyword could be contemplated? I'm not really sure  
whether `mv' would be the best choice here. how about replant or  
something like that (not that one could do that with branches on a real  
tree ...) to emphasize that this is a rename of a special kind? it's a  
long word to type but it should not happen that often.

--
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] workflow question

[j. van den hoff]

a colleague is considering to use fossil in a setup where he (the group  
leader) supervises several students having dedicated tasks within a larger  
project. what he would like to do is


* set up master repo

* give student(s) clone/pull/push permisisons for the repo

* require student(s) to branch immediately to individual feature  
branches (not fossil private branches, or anything, but just an ordinary  
branch assigned to the person and his task)


* request students to perform all work on their individual branches, while  
allowing them to merge in changes from trunk.


* supervisor looks at results/milestones of students in turn and merges  
the branches into trunk as he sees fit.


the request to work on branch is the catch: he wants to ensure that  
students can never mess up trunk, i.e. must technically not be able to  
merge anything into trunk. in the end he asks for branch-specific user  
capabilities. my understanding is that this is not possible in fossil. if  
so, are there any recommendations how a simple and easily manageable  
workflow having this functionality (prevent trunk from getting spoiled)  
could look like?


or are there better workflows/alternatives which would serve such a  
hierarchical development model? it should be a frequent requirement...



thx/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] workflow question

[j. van den hoff]

On Wed, 27 May 2015 18:05:15 +0200, Andy Bradford  
amb-sendok-1435334716.iohaonjclphfcadgm...@bradfords.org wrote:



Thus said j. van den hoff on Wed, 27 May 2015 12:10:57 +0200:


the request to work on branch is  the catch: he wants to ensure that
students can never mess up trunk, i.e. must technically not be able to
merge anything into trunk.


Trunk in  *which* clone  of the repository?  Perhaps the  teacher should


ideally the clones should never really diverge and be all used in  
'autosync' mode against the 'master'.



retain a  ``golden master'' clone  of the repository somewhere  to which
only  he  is allowed  to  push  changes  and  changes are  reviewed  and
corrected first.


yes, essentially that was my proposal to him, too.




in  the  end  he  asks   for  branch-specific  user  capabilities.  my
understanding is that this is not possible in fossil.


It depends on  what you allow for ``possible.'' If  each student clones,
pulls, and pushes from a unique clone of the repository then any changes
they  make will  only  be  synchronized when  whoever  controls all  the
repositories syncs them to the aforementioned ``golden master.''

Consider the  following where project1  is cloned once for  each student
and the teacher  pulls content from each one into  the ``golden master''
only  after it  has been  reviewed and  corrections made  (e.g. mistakes
merged into trunk).

Student1 clones http://host/projects/project1/student1
Student2 clones http://host/projects/project1/student2
Student3 clones http://host/projects/project1/student3

For  this to  work,  access to  project1/student1  could be  temporarily
disabled to prevent  race conditions with commits arriving  after it has
been  scrutinized  but before  it  has  been  pulled into  the  ``golden
master.''


if  so,  are  there  any  recommendations  how  a  simple  and  easily
manageable  workflow having  this  functionality  (prevent trunk  from
getting spoiled) could look like?


I'm not sure that what I mentioned  above is easy. I imagine it could be
made easier with some scripting.


yes, I would say, that would be necessary in this case. but it would work,  
I agree.




But, given  that these are students,  why not allow them  to spoil trunk
occasionally? If  they are truly  students, will  not this be  a perfect
time for them to learn and discover? After all, do not we learn from our
mistakes?


to some extent, yes :-)



Just a thought,


thank you for sharing them

joerg



Andy
--
TAI64 timestamp: 40005565eb5d



--
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] workflow question

[j. van den hoff]

On Wed, 27 May 2015 18:49:46 +0200, David Mason dma...@ryerson.ca wrote:


I use Fossil in 2 ways with students.

1) for each research project I have a Fossil, and all Grad students  
working

on that project (and I) have commit access.  There are few enough people
that it works out.


I think that's what my colleague has in mind (small group using a 'star  
topology'). his idea was to put each student on a separate branch but that  
only he was going (and is allowed) to do merges of changes intro trunk  
from which in turn all students could merge back the aggegated changes  
into their branches. this works but only on the condition of mutual  
agreement that everybody is playing to the rules. if not, trunk could be  
spoiled by direct checkins or merges performed by some student updating to  
trunk. personally I would agree with richard ('no real problem here') as  
well as andy ('let them make mistakes and find out the hard way what  
problems this causes') but he (and sure other users as well) feels  
differently. so I'm following this thread with some interest, what will be  
the final consensus (dont' touch or some new idea turning up).


thx/j



2) for assignments, I create a Fossil per student and the student plus  
the

marker(s) and I have commit access.

The biggest problem is people committing binary blobs to the repo.  But
they can be shunned, if necessary, to manage repo size.

../Dave
​



--
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] workflow question

[j. van den hoff]

On Wed, 27 May 2015 19:24:38 +0200, Ron W ronw.m...@gmail.com wrote:


(Sorry, accidently clicked the Send button when trying to click the
unfold icon in the editor.)

On Wed, May 27, 2015 at 6:10 AM, j. van den hoff  
veedeeh...@googlemail.com

wrote:


the request to work on branch is the catch: he wants to ensure that
students can never mess up trunk



You could achieve a safety net, but preventing a student from
intentionally pushing changes to trunk is possible.

 Set trunk as private. Then students clone the master repo with fossil
clone --private URL localrepo.fossil. Then when they create their dev
branches, they fossil publish mybranch.

In fact, your friend could provide a script to do the clone, start the
branch and publish the branch.


thanks. I will notify my colleague of this proposal. maybe that fits his  
needs.


--
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] workflow question

[j. van den hoff]

On Wed, 27 May 2015 13:25:43 +0200, Richard Hipp d...@sqlite.org wrote:


On 5/27/15, j. van den hoff veedeeh...@googlemail.com wrote:

he wants to ensure that
students can never mess up trunk, i.e. must technically not be able to
merge anything into trunk.


When the students have a copy of the repo on their local machine, they
can override any permissions that anybody sets up and do absolutely
anything they want with their local repository.


yes, I'm aware of this. I also am not advocating that functionality myself  
but understand that it might be important for some. git people (if I  
understand my colleague right) seem to put quite some emphasis on this  
feature being crucial (is that correct??).




It would, in theory, be possible to deny a push to the student who
messed up trunk.  But Fossil has decided not to go that route, as it
adds an inordinate amount of complication both to Fossil itself, and
to the user experience and workflow.  For example, after the push is
denied, what does the student do with their repository then?  They
have to figure out how to undo the trunk damage they inflicted?
Reclone and start over?  How do they fix the problem?  It gets to be a
big mess rather quickly.


keeping in mind that I personally *don't* want/need this:  would it not be  
possible to provide some `fossil setting' entry where read-only branches  
are defined so that *local* checkins to that branch would be? this would  
of course not prevent a malign or stubborn student to unset this entry and  
go ahead with messing up both repos but it would prevent any accidental,  
unintentional checkin or merge to the 'wrong' branch (and document it in  
the fossil settings display). together with what you called 'push deny  
(which would really protect trunk at least on the server) this would then  
work to keep both repos consistent, no?


could such a voluntary restriction of local permissions on a per-branch  
basis make sense?




Fossil's approach to this is to implement mechanism, not policy.
People with push permissions can do pretty much anything they want
with the repository.  But they cannot hide what they have done.  They
cannot cover their tracks.  Fossil provides capabilities that make
it trival for the instructor to see that a student has pushed to
trunk, and to easily back out any changes to trunk.  So if the
instructor will merely glance at the timeline from time to time, he
can clearly see that a policy violation has occurred, and a few simple
commands will fix the damage done - either by fossil merge --backout
BADCOMMIT or if the rogue commit is the last one on the trunk, he can
move it to another branch.  Then he can deal with the student
adminstratively (ex: lower his project score).


personally, I agree and would proceed along these lines. but there are  
sure users with a different view who insist on a mechanism to prevent the  
bad checkins/merges in the first place.




The other approach would be to deny push privileges to the students
and force them to email in bundles that contain their changes, to be
added back to the trunk administratively by the instructor.  That's a
lot more work on the instructor's part, but it does guarantee that
nothing he does not want gets into the trunk.


a lot more work would make this unattractive, of course.






--
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] bug in `fossil finfo' output?

[j. van den hoff]

hi list,

I've reported this a week ago or so and presume it failed to draw any  
attention. therefore, with apologies of reporting the same thing twice I'd  
like to repeat the observed problem here:


`fossil finfo' output quite frequently does contain pairs of duplicate  
timeline entries at merge points. e.g. in the `fossil' source repo I see  
these duplicates in the output of `fossil finfo src/sha1.c':


* 2011-09-01 [02ee688a4d] Merge latest trunk. (user: dmitry, artifact:
[a088d4e44a], branch: symlinks)

* 2011-08-22 [c57830bec2] Merge trunk. (user: dmitry, artifact:
[40c07a366d], branch: symlinks)

* 2010-02-26 [df90572760] Merge in latest changes from trunk. (user:
linuxfood, artifact: [039460fa0a], branch: creole)

* 2009-10-05 [651c75c5b7] merge trunk into creole (user: robert, artifact:
[30e74752c3], branch: creole)

if someone wants to check other instances (e.g. in `fossil src/main.c'  
where there are many more duplicates to be found), here is a stupid script  
(expecting a single file name as argument, when called) reporting the  
duplicates:


#!/usr/bin/env sh
fossil finfo -W 0 $* | awk '
{
   if (!freq[$0]) lines[++cnt] = $0
   freq[$0]++
}
END {
   for (i = 1; i = cnt; i++) {
 multi = freq[lines[i]]
 if (multi  1) print multi  times:  lines[i]
   }
}'

if I am not missing some essential point, the present behaviour (duplicate  
records) is buggy. it would be good if someone knowledgeable could have a  
look.




joerg
___
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] About the help command

[j. van den hoff]

On Fri, 08 May 2015 21:14:07 +0200, Abilio Marques abili...@gmail.com  
wrote:


Ohhh, I did use dbstat the other day (several times actually) while  
working

with some binary files. But yeah, I know there is the -a list, plus the
hidden list. But I'm still happy to know that almost everything I use is  
at

hand, and that I don't need a cryptic combination or plainly wrong named
commands to do my work, at least compared with... yeah... you know which
I'm a genius so I'll hack a new one from scratch in less than 2 weeks
stupid content tracker I'm talking about...

Is just that I wanted to avoid a chain of critics about that other. I
honestly believe is a good software, but where it mostly excels is at
confusing the user, even with the ABC. That's my only critic to it.  
Fossil
is still years light away from confusing anyone that way, but it has  
gained
a couple of pounds in the last years. I believe there is room for  
improving
the way you can get references on how to use each command. I believe  
there
is room for improvements in the online documentation too. I want this  
email

chain to be around that idea.


you are sure right. personally, I'd like to see `fossil help' somewhere on  
the level of `hg help'. the `mercurial' people really invested substantial  
effort in getting the help system right in my view: one nice idea is that  
`hg help' does not just list the commands but also gives at least a hint  
at what each command does. moreover, `hg' provides metapages (listed by  
`hg help', too) such as `hg help config'. I believe the  `hg' help also is  
quite comprehensive. with `fossil' there still seem to be some gaps here  
and there and/or the structure is awkward (e.g. the `cherrypick' and  
`backout' options are for some reason only mentioned in the explanation of  
`merge' but are not listed together with the othr options -- no idea why).


but of course someone would have to be willing to invest his time for (and  
be capable of) improving the help system instead of the functionality --  
and the latter still should have priority in the end, probably ;-)



--
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] bug in CLI `fossil finfo' output?

[j. van den hoff]

I encounter dublicate entries in the output from `fossil finfo someFile'  
(`fossil timeline' is not affected)

when forks are merged. e.g.:

2013-06-20 [e183f11d6a] intermediate stage of `churn' overhaul. (user:  
vdh, artifact: [4705fc57d1], branch: trunk)
2013-06-20 [70509c0933] just to make the merge visible... (user: vdh,  
artifact: [33705c4c72], branch: trunk)
2013-06-20 [70509c0933] just to make the merge visible... (user: vdh,  
artifact: [33705c4c72], branch: trunk)
2013-06-20 [69353cd4cf] typo/bug fix. (user: vdh, artifact: [9db0c40886],  
branch: trunk)



in the webui the same part reads:

in the timeline:

2013-06-20 13:09		[e183f11d6a] intermediate stage of `churn' overhaul.   
(user: vdh, tags: trunk)
2013-06-20 00:15		[70509c0933] just to make the merge visible...  (user:  
vdh, tags: trunk)

2013-06-20 00:05[69353cd4cf] typo/bug fix.  (user: vdh, tags: 
trunk)


in the file history:

13:09		[4705fc57d1] part of check-in [e183f11d6a] intermediate stage of  
`churn' overhaul. (user: vdh branch: trunk)  [annotate]  [blame]  
[check-ins using] [diff]
00:15		[33705c4c72] part of check-in [70509c0933] just to make the merge  
visible... (user: vdh branch: trunk)  [annotate]  [blame] [check-ins  
using] [diff]
00:05		[9db0c40886] part of check-in [69353cd4cf] typo/bug fix. (user: vdh  
branch: trunk)  [annotate]  [blame] [check-ins using] [diff]



I hope this is reproducible for someone else and presume it is a bug in  
`fossil finfo' CLI output?


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

[fossil-users] bug in CLI `fossil finfo' output?

[j. van den hoff]

I have checked the problem of duplicate entries reported by `fossil finfo'  
a bit further: fossil's own repository demonstrates the problem as well.  
e.g., I see the following duplicate entries in `fossil finfo src/sha1.c'  
(src/main.c yields *lots* more ...):


* 2011-09-01 [02ee688a4d] Merge latest trunk. (user: dmitry, artifact:  
[a088d4e44a], branch: symlinks)


* 2011-08-22 [c57830bec2] Merge trunk. (user: dmitry, artifact:  
[40c07a366d], branch: symlinks)


* 2010-02-26 [df90572760] Merge in latest changes from trunk. (user:  
linuxfood, artifact: [039460fa0a], branch: creole)


* 2009-10-05 [651c75c5b7] merge trunk into creole (user: robert, artifact:  
[30e74752c3], branch: creole)


it also seems, the problem is not restricted to merging of forks but  
affects other merges as well (although not all of them ...).


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

[fossil-users] CLI timeline formatting issue

[j. van den hoff]

a minor thing but it causes me a bit of grief right now: currently, the  
timeline output is using whitespace as well as `-' as word boundaries when  
performing line wrapping/breaking. line wrapping can also happen,  
therefore, in the middle of branch names containing a minus, such as  
`sync-forwarn'. this might be OK if solely considered as a question of  
correct hyphenation of dashes-containing words. but I'd rather see  
branch names not split across two lines. and it comes really in the way if  
one wants to colorize the timeline output by a wrapper/filter injecting  
ansi color codes into the output since it would require special tests for  
the case where a `-' (minus) is the word boundary since the color codes  
cannot span multiple lines etc.


a minor request/question: could/should the line wrapping not be restricted  
to using real white space as word boundaries?


thx/joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] status of sha1 reporting in timeline?

[j. van den hoff]

I think I found the answer myself: the relevant checkin seems to be  
[1fee0377e4] (feb. 11, 2015). sorry for the noise.


On Tue, 28 Apr 2015 15:43:43 +0200, j. van den hoff  
veedeeh...@googlemail.com wrote:


  I lost track of what exactly has happened w.r.t. to the previously  
variable-length sha1 reporting (to enforce occurrence of at least one  
from a-f in the displayed substring) in `timeline' and friends? at least  
`timeline' now seems to use the 10 digits fixed-width format. question:  
can wrapper scripts from now on (or since when exactly) safely assume a  
fixed length of 10 digits?


thx/joerg




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Testing. Was: Two trunks?

[j. van den hoff]

On Sun, 26 Apr 2015 19:51:44 +0200, Matt Welland mattrwell...@gmail.com  
wrote:



I like this idea. I will test this branch Monday.

+1

On Sun, Apr 26, 2015 at 10:16 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:


2015-04-26 12:54 GMT+02:00 Richard Hipp d...@sqlite.org:
 Yes, but it is not a fork.  And so we shouldn't call it fossil forks
 since that would prevent us from creating a fossil forks command
 that actually lists real forks.

 Perhaps the command should be fossil warnings or fossil concerns
 and it should report all topological features that are worrisome to
 some users.  (Are there any other graph topology features besides
 multiple leaves on the same branch that people are concerned about?)

Or, maybe just combine it with fossil info and use the more general


+1


term ambigeous branch (of which fork is a special case)


which term many people would not understand, I'm afraid... some other  
wording would be better I believe. actually the previous description  
multiple leaves on trunk (or branch XXX) seems much clearer to me.




https://www.fossil-scm.org/index.html/info/4359bd8df2119799

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




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

[j. van den hoff]

On Sat, 25 Apr 2015 03:03:50 +0200, Andy Bradford  
amb-fos...@bradfords.org wrote:



Thus said Richard Hipp on Sat, 18 Apr 2015 09:53:53 -0400:


Proposed solutions  include denying  the ability to  commit or  push a
fork. But doesn't that just make the problem worse?


Yes, I think it does make it  worse; this is not a practical approach in
my opinion.  I think it  better to have the  fork and receive  a warning
about it, or see it in the timeline than deny it.


We've  already established  that users  are in  the habit  of ignoring
scary fork warnings.


If they've seen them. They may not be seeing them due to infrastructure.
E.g. User1 syncs to site1.dom and  User2 syncs to site2.dom, where there
is a 10 minute synchronization delay between site1.dom and site2.dom. If
User1 and  User2 checkin  against the  same leaf  within that  10 minute
window, currently neither will get a warning about forks.



Other proposed changes include more  frequent nagging about forks. The
issue is less clear-cut, but I still worry that it might contribute to
warning fatigue. I go by the motto that you should always distrust any
computer  program that  thinks it  knows  more than  you do.  Constant
nagging about forks seems to move  Fossil in the direction of programs
that I  would not trust.  This is not to  say that there  shouldn't be
warnings, but there needs to be balance.


I too  was worried about  warning fatigue. It  should warn as  little as
possible.  How  to achieve  that,  while  also providing  more  advanced
warning to those who want it is a difficult challenge.

I also am not fond of computer programs that behave as if they know more
than I do; this is one of the reasons why I prefer Fossil over Git. :-)

Regarding the balance for fork warnings,  where there seems to be a high
volume of  forks, will additional  notification help prevent  the forks?
Probably not because a fork is  something that has already occurred, but
it might  help them be  resolved more quickly  as they will  be detected
sooner. Specifically,  I'm talking about  the kind of fork  that happens
silently that goes  undetected for whatever reason. For  a project where
fork volume is low, will more notifications be a hindrance?

I've sought to create a balance  in the sync-forkwarn branch between the
frequency of the nag and when to nag.  For example, it will not nag on a
clone---what's the point? It also won't  nag if the artifact received is
part of a fork  previously existing in the clone (again,  no need to nag
continuously  about a  checkin against  a  fork that  should already  be
known). But it will nag if you receive an artifact that has caused a new
fork in your clone. The first person  to generate a fork will be the one
to get the  first notification, and if they address  it, no other people
will be notified.

Are  these  changes reasonable?  Does  it  fit the  parsimoniousness  of
Fossil? Or is it too much?

How  many   forks  in   Fossil  were   done  intentionally   (e.g.  with
--allow-fork)? How many were unintentional  and would have been resolved
more  quickly  had a  warning  been  issued at  the  time  the fork  was
synchronized?


I believe having these warnings would be good and would opt for making a  
field test whether it is well accepted or not in the fossil users  
community. regarding 'notification overload'. I always found and still  
find part of the regular fossil output to verbose.
e.g. doing a `fossil up' when already in sync with the server (with  
autosync on) one gets 8 lines of output the only two being really relevant  
being the one confirming that pulling is under way and the 'changes' linen  
stating that nothing has changed.


and probably the average user will not care how many artifacts have been  
sent or received but only would like to see some sort of progress feedback  
I presume. what I mean is: at a few places there might be a suboptimal  
signal to noise ratio in the default output and the relevant ones like  
failure to sync or detected forks should stand out sufficiently.


another idea: maybe `fossil info' could also include a warning line if  
there are any forks at present?


thx/j



Thanks,

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] Bug? FOSSIL MV does not work as expected (Win7 machine)

[j. van den hoff]

On Tue, 21 Apr 2015 11:09:05 +0200, Jan Nijtmans jan.nijtm...@gmail.com  
wrote:



2015-04-21 10:24 GMT+02:00 Michael Richter ttmrich...@gmail.com:

The key wording there is within the repository tree.

It doesn't change the file system, only the naming of the files, etc.  
in the
repository.  Whether this is desired or correct behaviour is … an area  
of

frequent discussion.


Work already has been done by Joe Mistachkin to resolve this (Thanks  
Joe!)


Just configure fossil using --with-legacy-mv-rm and then build it, then:
./fossil set mv-rm-files -global 1

I'm currently using fossil compiled this way, and so far it appears to
work fine.


any chance to see this becoming the default soon?



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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] auto-adjust of CLI timeline to terminal width?

[j. van den hoff]

On Mon, 20 Apr 2015 23:00:57 +0200, Warren Young w...@etr-usa.com wrote:

On Apr 20, 2015, at 1:43 PM, j. van den hoff veedeeh...@googlemail.com  
wrote:


why does it fail for me on one machine (linux) but not on the other  
(macos)?


It’s a bug in the #includes at the top of src/comformat.c.  The  
following trivial patch fixes it:


Index: src/comformat.c
==
--- src/comformat.c
+++ src/comformat.c
@@ -23,13 +23,11 @@
 #include assert.h
 #ifdef _WIN32
 # include windows.h
 #else
 # include termios.h
-# if defined(TIOCGWINSZ)
-#  include sys/ioctl.h
-# endif
+# include sys/ioctl.h
 #endif
#if INTERFACE
 #define COMMENT_PRINT_NONE   ((u32)0x) /* No flags. */
 #define COMMENT_PRINT_LEGACY ((u32)0x0001) /* Use legacy  
algorithm. */




The code is apparently written with the assumption that TIOCGWINSZ is  
found in termios.h, but it’s actually found in one of the buried  
asm/noisenoise.h files underneath sys/ioctl.h.  Thus, by skipping  
sys/ioctl.h, TIOCGWINSZ is never defined, so the output takes the  
“legacy” path.


I have not checked whether this patch causes a portability regression.   
If there is in fact a platform where you cannot include sys/ioctl.h if  
TIOCGWINSZ isn’t defined by termios.h, a different ifdef will be  
required.


thanks! I can confirm that you are right and with this patch it runs just  
fine under linux. hope this fix (or something similar) will make it intro  
trunk... .


___
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] auto-adjust of CLI timeline to terminal width?

[j. van den hoff]

On Mon, 20 Apr 2015 22:10:31 +0200, jungle Boogie  
jungleboog...@gmail.com wrote:



Hello,
On 20 April 2015 at 12:43, j. van den hoff veedeeh...@googlemail.com  
wrote:

hi,

just curious: today I accidentally noted -- accidentally, since I  
usually

use it only through a wrapper reformatting the timeline -- that `fossil
timeline' now seems to auto-adjust to the terminal width (i.e. only does
wrap around of the commit message at the given right margin of the  
window),
which really is a substantial improvement in my view. at least that is  
what
I see on my Mac, both in the Terminal.app as well as under X11 in xterm  
und
urxvt. however, on our (linux) server with the same current fossil  
version
this is not the case and the wrap around still happens at a fixed width  
as

it used to be in the past. questions: is this actually new implemented
behaviour (I cannot find it in the recent timeline comments, e.g.)? does
fossil now really query the terminal width? if yes, why does it fail  
for me

on one machine (linux) but not on the other (macos)?
any ideas?




Reading from this:
https://www.fossil-scm.org/index.html/help?cmd=timeline

 -W|--width num Width of lines (default is to auto-detect). Must be
   20 or 0 (= no limit, resulting in a single line  
per

   entry).



I know of the -W flag but failed to note the reference to `default is to  
auto-detect', thank you. this indeed seems to indicate that the line width  
is adjusted to the terminal width (which is good). in fact that is what I  
have seen on my mac, but _not_ on the linux machine when logging in via  
ssh (terminal or thinlinc client) where indeed it seems to default to `-W  
80' or similar. why is that? don't see what sort of problem with  
environment variables this could be.




% fossil timeline -W 80
=== 2015-04-20 ===
18:58:38 [41c9543916] *CURRENT* Many new configuration options for  
fuzzershell.

 (user: drh tags: trunk)
18:48:57 [2ea8f9cbe6] Fix some fts5 problems with very large position  
lists.

 (user: dan tags: fts5)
15:13:08 [2f58c8c972] Fix a memory leak caused by duplicate entries in  
the

 sqlite_stat1 table. (user: dan tags: trunk)
13:59:18 [c72abbe2c1] Fix an obscure memory leak in  
sqlite3Stat4ProbeFree()

 (user: drh tags: trunk)
12:50:13 [ab0a96ca73] Enhance fuzzershell to support multiple blocks of  
SQL,
 each run in its own private in-memory database. (user: drh  
tags: trunk)
01:32:53 [b8ef1cdee3] *MERGE* Merge all recent trunk enhancements and  
fixes

 into the sessions branch. (user: drh tags: sessions)
01:25:56 [74b7bf1744] *MERGE* Merge all recent trunk enhancements and  
fixes

 into the apple-osx branch. (user: drh tags: apple-osx)
01:13:33 [592c010478] Add an ALWAYS() around a new branch that was made
 unreachable by an even newer change. (user: drh tags: trunk)
=== 2015-04-19 ===
23:48:10 [5ae853aaeb] Fix another harmless compiler warning. (user:  
mistachkin

 tags: vsix2015)
--- line limit (20) reached ---


And when I change the 80 to 200, I see more entries but I can show you
on email as it will wrap.
Here's the pastiebin:
http://pastiebin.com/55355b504c161

Without the -W 200, my output is pretty much what's above.

All above is on a freebsd machine.

Interestingly when I connect to my raspberry pi tmux session and run
fossil timeline, it defaults to the 80 width.

Just checked, also defaults to 80 over ssh.

maybe its some environmental variable but at least we know of a way to
display more that 80 width.



thx/j


--
Using Opera's revolutionary email client: http://www.opera.com/mail/





--
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] auto-adjust of CLI timeline to terminal width?

[j. van den hoff]

hi,

just curious: today I accidentally noted -- accidentally, since I usually  
use it only through a wrapper reformatting the timeline -- that `fossil  
timeline' now seems to auto-adjust to the terminal width (i.e. only does  
wrap around of the commit message at the given right margin of the  
window), which really is a substantial improvement in my view. at least  
that is what I see on my Mac, both in the Terminal.app as well as under  
X11 in xterm und urxvt. however, on our (linux) server with the same  
current fossil version this is not the case and the wrap around still  
happens at a fixed width as it used to be in the past. questions: is this  
actually new implemented behaviour (I cannot find it in the recent  
timeline comments, e.g.)? does fossil now really query the terminal width?  
if yes, why does it fail for me on one machine (linux) but not on the  
other (macos)?

any ideas?

thx/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] Two trunks?

[j. van den hoff]

On Sat, 18 Apr 2015 15:53:53 +0200, Richard Hipp d...@sqlite.org wrote:


Fossil has, for many years, detected potential forks prior to commit
and warned about them, or within the past few years has disallowed the
commit completely without the --allow-fork option.  If two users are
committing concurrently, the fork detection fails, but even then the
second user gets a message  warning: a fork has occurred *.
The problem arises when the second user does not notice, or chooses to
ignore, this message and the situational awareness within the
organization is such that nobody notices the fork plainly displayed on
the timeline.  The check-in on the fork gets overlooked and fails to
make it into the next release.

Proposed solutions include denying the ability to commit or push a
fork.  But doesn't that just make the problem worse?  We've already
established that users are in the habit of ignoring scary fork
warnings.  Wouldn't they also just ignore the fact that the commit or
push failed?  With a fork, at least the content is safely on the
server and can be easily recovered by anybody willing to take a moment
to review the timeline.  But if the change never gets pushed, the
content is only on the developer's machine, out of view and
unrecoverable by anyone except the original developer.  And if it
never gets committed, then the work might be lost even to the original
developer.  How is that an improvement?

Other proposed changes include more frequent nagging about forks.  The
issue is less clear-cut, but I still worry that it might contribute to
warning fatigue.  I go by the motto that you should always distrust
any computer program that thinks it knows more than you do.  Constant
nagging about forks seems to move Fossil in the direction of programs
that I would not trust.  This is not to say that there shouldn't be
warnings, but there needs to be balance.

The fossil update|co|checkout BRANCH command takes you to the most
recent check-in for BRANCH.  If BRANCH contains leaves that are not
the most recent check-in, it seems like this would be a good time to


yes.


issue a warning.  The command might even fail with the message that
BRANCH is ambiguous and then provide a list of all possible SHA1
values that BRANCH could resolve to, enabling the user to retry the
command with an unambiguous SHA1 hash.


no. I believe the checkout should just proceed as it precently does in  
this case. it seems clear that the intent of `fossil up BRANCH' is just  
that, rather than going to any of the fork-related leaves.




Another approach would be to provide commands (such as fossil forks)
that actually show problems in the tree, for people who are actually


that would be very good. as forks are sometimes simply spurious (there  
were some never-quite-cleared-up reports in the past of forks suddenly  
appearing even in single-developer projects -- I, too, experienced this at  
least onece) or due to erroneous checkins. I would argue for restricting  
the list by default to unclosed fork leaves so that the reported list of  
forks is restricted to the forks still not dealt with (either are not just  
closed or not yet merged back). maybe this list could additionally be  
generated by `fossil branch' like


trunk
dev
experimental
--
unresolved forks:
  {sha1} (parent branch: {parent branch} dated {date})

so that it can be noted by the user even if he is not explicitly hunting  
for the forks.



interested - for example the release manager.  A web-version of
fossil forks with graphical pictures of each fork would be nice to
have.


CLI seems rather more important to me, but yes, it would be nice.



One other thing:  We ought to intentionally preserve several forks
within the Fossil self-hosting repository, so that we always have test
cases for the above mechanisms readily at hand.


I believe somewhere in this thread it was argued that forks can be  
intended/beneficial. I feel that such use should be officially  
discouraged and to proceed from a consensus that (unclosed) fork-leaves  
should be taken as indicator of a lurking problem in the project.



--
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] Merge - including files from other branches - best practice?

[j. van den hoff]

On Fri, 17 Apr 2015 06:56:13 +0200, Andy Bradford  
amb-fos...@bradfords.org wrote:



Thus said Scott Robison on Thu, 16 Apr 2015 21:00:50 -0600:


Partly I think it is because your  test case consists of a single file
of a  single line, which  means probably  (I would think)  every merge
resulted in a conflict that you had to resolve manually.


Yes, every  merge is a conflict  which I resolve arbitrarily  by leaving
just one of the conflicting changes.


Effectively, the  line from  newbranch was deleted  and the  line from
trunk was inserted, so  by the time of the merge  there is nothing new
or changed in newbranch to merge into trunk.


That's effectively what  seems to be happening. Even  though ``file'' is
different on newbranch, when I merge  it into trunk, it doesn't consider
the contents of ``file'' as  being in conflict---which surprised me. All
other merges  resulted in conflict resolution  that had to happen.  So I
was expecting  conflict resolution when  I merged in  the branch---there
was none.

I'm still a  bit confused why it  didn't think there was  a conflict and
just chose instead to take the content from trunk (which is why it shows
no differences).


+1: I, too, don't really get it, why a file deletion should be treated  
differently from edits to the file (including the case where an empty file  
would be the result). at merge time, all conflicting differences between  
both branches should be reported and would nee manual resolution. so if  
`foo' had been deleted in the past on trunk and later a new file of that  
name is created on the branch, it would seem correct to handle this as a  
conflict just as if `foo' still where in existence on trunk whereas if  
`foo' never has existed on trunk in the first place, the new file from the  
branch should simply be merged as a non-conflicting difference. what am I  
missing?




Thanks for your response.

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] terminology confusion

[j. van den hoff]

On Thu, 16 Apr 2015 22:58:55 +0200, Ron W ronw.m...@gmail.com wrote:


On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison sc...@casaderobison.com
wrote:


Some thoughts:

More seriously, the Wikipedia article on forking is probably worth a  
read:

http://en.wikipedia.org/wiki/Fork_(software_development)

I would claim that github is the odd man out here, having appropriated a
term that historically meant something undesirable and changing it into  
an

intended desirable part of the software development process.



Certainly, Github's use of fork is different that saying Devuan is a
fork of Debian.

As to whether a fork is undesirable depends on point of view. I am
willfully ignorant regarding the Debian people's opinions of Devuan. I
will, however, admit that I think the Inkscape fork of Sodapodi benefited
me,



Accidental head or accidental branch don't seem to apply if for no other
reason a fork *can* be deliberate. That's not the norm but --allow-fork
does exist as an option for those cases when fossil can detect a fork  
will

happen but to allow it anyway. I suspect most people don't type
--allow-fork accidentally (when they type it at all). :)



In my experience, a fork results when I or one of my teammates forgets  
to

start a new branch. So, from our perspective, accidental is very
applicable. Even with fossil forks, such an undistinguished branch
would be easy to loose track of. I would not want to create a fork.


So, if we *must* have a unique term, I'd vote for twig as I've never  
heard
it used in a dvcs context and can't find such a reference via Google.  
Mind
you, if we started using twig there is nothing to stop github (or  
others)

from coming along and appropriating the terminology, so we could wind up
right back in this position seven years down the road.



I'm not saying _must_. I only want to point out that it could be a
non-trivial obstacle to adoption for Fossil for some people.


personally, I don't see a problem with calling such random branches a fork  
within the fossil context. but I agree that the use/meaning is a bit  
idiosyncratic in view of the existence of 'project forks' and  
(unfortunately) github calling the project clone maintained on the server  
side a fork (I believe that's what it is, right?).


semantically, it might be stated that fork somewhat breaks the tree  
paradigm (trunk, branch, leave...) or at least introduces a topological  
property where otherwise components are used. so the suggestion to  
change to twig might really be a good thing. but if changing the  
terminology really is a seriously considered issue, than I cannot abstain  
from proposing shoot instead (which would open the theoretical  
possibility to indicate it as `SHOOT!' in the CLI timeline display --  
which most of the time, would be correct, too ;-)


but seriously: maybe all is good and well already ...


--
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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories

[j. van den hoff]

a marginal point, but in case you care: the german word for  
repository/deposit actually is Lagerstätte where the diacritical mark  
over the `a' really matters. but Lagerstatte sounds really awful (since  
the a is pronounced like the u in the English word `up', while the ä  
is similarly pronounced to English a in action). and it simply looks  
misspelled ;-). it also seems not to belong to the words having been  
assimilated into english after spelling changes (such as iceberg) as far  
as I know.


to make german users a bit more happy you might call it lagerstaette  
where the `ae' is a widely used ASCII approximation of the ä (in  
germany, anyway). also note, that Lagerstatt (the singular form of  
Lagerstätten (with final n)) is an exalted way of denoting a bed (and  
not a place were to store fossils (or beer ;-)). overall, I'm not sure  
whether the name choice was a lucky one...


regards/joerg

On Mon, 30 Mar 2015 12:50:54 +0200, Vikrant Chaudhary  
vikr...@webstream.io wrote:



Hello everyone,

I've been working on a project named Lagerstatte, a front-end for
Fossil repositories. The browser facing part is written in Ember.js,
while server runs a Ruby on Rails application which acts as a JSON
endpoint. Access to Fossil database is provided by Stephan's excellent
libfossil library.

I'd also like to emphasise that this a very early announcement. The
project is far from even a beta stage. With this email, my sole
intention is to make Fossil community aware of the project.
Lagerstatte is a work-in-progress and may do anything it likes up to
and including eating your laundry.

Features that you can evaluate today:

* Navigating through files.
* Viewing latest revision of wiki pages.
* Access the Fossil repositories through Git protocol (readonly).

Planned features:

* Installation instructions  documentations.
* on-premise behind-firewall installations.
* Fully featured code, wiki, and issues management.
* Email notifications.
* LDAP / OpenID Connect authentication.
* Searching across multiple repositories.
* Basic elements of social networking  project discovery.
* Unified login across all repositories.
* One-click repository setup.
* Fault-tolerant and high-availability storage of Fossil repositories.
* Cheap forking (I have some ideas on how to achieve this in  
Fossil/libfossil).

* Cross-fork merge-requests.
* API, Notifications, Webhooks,  OAuth for integration with  
third-parties.

* Graphs  Statistics.

A preview of Lagerstatte-in-action is available at https://codeflow.io/

Lagerstatte:
Web/Fossil: https://codeflow.io/lagerstatte/lagerstatte
Git: http://git.codeflow.io/lagerstatte/lagerstatte

fossil_ruby:
(a Ruby wrapper for libfossil)
Web/Fossil: https://codeflow.io/lagerstatte/fossil_ruby
Git: http://git.codeflow.io/lagerstatte/fossil_ruby

libfossil:
Web/Fossil: https://codeflow.io/libfossil/libfossil
Git: http://git.codeflow.io/libfossil/libfossil

Fossil:
Web: https://codeflow.io/fossil/fossil
Git/Fossil: Too awesome to handle by currently inefficient git
conversion code. I've some ideas on improving this, which I'm working
on.

I'll be adding more repositories soon to the list (SQLite3, SQLite4,
Tcl, Tk, and more). If you'd like to see your repository at Codeflow,
let me know.

Subscribe to mailing-list for discussions and development updates!
https://groups.google.com/forum/#!forum/lagerstatte
Feedback, suggestions, and contributions are welcome.

About name:
A Lagerstätte is a sedimentary deposit that exhibits extraordinary
fossils with exceptional preservation. -
https://en.wikipedia.org/wiki/Lagerstätte

Stephan and me had a lengthy discussion on transliteration of
Lagerstätte to ASCII. Candidates were Lagerstaette and
Lagerstatte. (more context: http://german.stackexchange.com/q/4992).
Following up on the trend of several previous German loanwords in
English, we decided to go with Lagerstatte.

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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] strangeness

[j. van den hoff]

hi list,

I have encountered a strange behaviour (of course right now no longer  
reproducible ...).


setup:

-- ssh-transport, all permissions fine
-- local clone configured to use 'autosync'
-- locally running some variant of 1.32, remotely of 1.31 (so updated  
recently)
-- two year old repos (so definitely created with distinctly older  
versions of fossil)


now for the ufos:

1.
yesterday I tried `fossil ci' after some edits which led to a silent  
return to the prompt without any actions having been taken. only after 2  
further tries the editor popped up for entering the ci message and the ci  
actually proceeded (and also propated to the server as it should, given  
the `autosync' setting


2.
today I did 2 checkins just fine (seemingly) including getting the  
autosync-related messages generated by fossil. but after the checkin the  
changes had not propagated to the remote repo. I had to do an explicit  
push to get the changes there.


In a couple of years using fossil I have never encountered something like  
this. any ideas what might be going on here?


thx/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] strangeness

[j. van den hoff]

On Fri, 27 Mar 2015 18:06:34 +0100, bch brad.har...@gmail.com wrote:


Without further information 1) reminds me of quick edits whereby the
timestamp (fossils cheap way of discovering change) may not have
chnanged ? The foolproof (expensive) way of determining changes is
to checksum ea. file (ie: fossil  changes --sha1sum)


I agree, it could be related to something like that, but ...


What are the conditions that you're editing under, or is there
anything that may be advancing  the timestamp outside your initial
(failed-to-commit) edits ?


wouldn't know how this should have happened: these were small edits but  
sure not performed within one second or whatever the granularity of the  
timestamp is. I'll have to wait and see whether the problem comes back. in  
this case I will try to investigate it more thoroughly. in any case  
problem no. 2 is more irritating. I have no idea how fossil could accept  
the checkin locally without propagating the checkin to the remote url  
despite 'autosync on' and without throwing an error...


joerg



-bch

On 3/27/15, j. van den hoff veedeeh...@googlemail.com wrote:

hi list,

I have encountered a strange behaviour (of course right now no longer
reproducible ...).

setup:

-- ssh-transport, all permissions fine
-- local clone configured to use 'autosync'
-- locally running some variant of 1.32, remotely of 1.31 (so updated
recently)
-- two year old repos (so definitely created with distinctly older
versions of fossil)

now for the ufos:

1.
yesterday I tried `fossil ci' after some edits which led to a silent
return to the prompt without any actions having been taken. only after 2
further tries the editor popped up for entering the ci message and the  
ci

actually proceeded (and also propated to the server as it should, given
the `autosync' setting

2.
today I did 2 checkins just fine (seemingly) including getting the
autosync-related messages generated by fossil. but after the checkin the
changes had not propagated to the remote repo. I had to do an explicit
push to get the changes there.

In a couple of years using fossil I have never encountered something  
like

this. any ideas what might be going on here?

thx/j

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] strangeness

[j. van den hoff]

On Fri, 27 Mar 2015 21:13:47 +0100, Andy Bradford  
amb-sendok-1430079228.ndeleinmkbfcohhpc...@bradfords.org wrote:



Thus said j. van den hoff on Fri, 27 Mar 2015 14:37:32 +0100:


In a couple  of years using fossil I have  never encountered something
like this. any ideas what might be going on here?


The only time I've seen Fossil due inexplicable things like this is when
I  had recently  updated  and recompiled  without  first removing  stale
object files.


ah... yes, that I might have done as well (just updating fossil and  
hitting `make' w/o a `make clean' first).


thanks for this hint.

joerg



Andy
--
TAI64 timestamp: 40005515ba1d



--
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] strangeness

[j. van den hoff]

On Fri, 27 Mar 2015 21:15:58 +0100, Andy Bradford  
amb-sendok-1430079359.djinpnjliidbjojff...@bradfords.org wrote:



Thus said j. van den hoff on Fri, 27 Mar 2015 20:37:37 +0100:


in any  case problem  no. 2  is more  irritating. I  have no  idea how
fossil  could  accept  the  checkin locally  without  propagating  the
checkin to the  remote url despite 'autosync on'  and without throwing
an error...


Yes, that one is also quite odd... What about:

fossil settings dont-push


no, not at all. the only relevant setting is autosync(local)  on...  
as I said: I will wait and see whether it occurs again and then try to  
provide more details.


joerg



Andy
--
TAI64 timestamp: 40005515baa0



--
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] possible error

[j. van den hoff]

On Tue, 17 Mar 2015 17:06:33 +0100, Ramon Ribó ram...@compassis.com  
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?


yes, if you have defined a remote URL via `fossil remote-url URL' it  
should work.




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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] GitHub question. Was: Git-v-Fossil.

[j. van den hoff]

On Sat, 14 Mar 2015 10:18:35 +0100, Stephan Beal sgb...@googlemail.com  
wrote:



On Sat, Mar 14, 2015 at 5:05 AM, Richard Hipp d...@sqlite.org wrote:


I tried going to the network graph
(https://github.com/mackyle/sqlite/network) which seems similar to the
Fossil timeline graph, only sideways.






I needed to use github only once, fortunately, when I wanted to contribute  
a small patch to `asciidoc', so I am really a test case for how does  
github feel to a newbie. answer: awkward, to say the very least. this is  
quite different to first time encounter with `fossil'. so one probably  
should not look to closely on github on how to improve `fossil'. ;-)


The network is primarily intended to show fork-related relationships.  
i.e.

whose fork was created/merged at what point. In a way it's similar to the
branch handling in fossil's timeline. github's workflow encourages using
forks rather than branches (the end effect is similar, since a fork can  
be

merged in at any time).


my understanding was that a github fork is nothing but a clone and not  
really part of the original project, no? so it really is not comparable  
to a branch (be it `git' or `fossil'), no?


in my (probably naive or wrong) view github seems nothing more than a way  
to manage changes in different clones of a project which are suggested  
for cherry-pick merge into the main repo (plus a lot of eye candy I for  
one find distracting rather than helpful). so github as far as I can see  
is only a metastructure on top of `git' and this functionality might (or  
might not) be mimicked as part of `fossil' or via some sort of  
`fossilhub'. I see that github is immensely successful so no sense arguing  
that something like that seems desirable.


just my 2c (probably explaining the very obvious ;-))

j.

re



Am I wrong to think that clicking through the changes in a project

(not necessarily from the beginning, but from some signification
event, say the most recent release) in chronological order is
something that people might commonly want to do?



It's possibly a case of not missing what one never had.

Some tools, e.g. Google Code, offer the ability to move forward and
backward through commit numbers. e.g. see the links near the top/right of
this SVN browser:

https://code.google.com/p/v8-juice/source/browse/convert/include/cvv8/XTo.hpp?r=2070

But that's at the file level. It has a timeline-like view, but it's not
nearly as informative as fossil's:

https://code.google.com/p/v8-juice/source/list

(But it's easy enough to find the start of the project there.)

Haven't ever spent enough time in github to notice if/how it does  
something

similar.




--
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] Justification for two-step mv and rm

[j. van den hoff]

On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna tont...@ultrareal.de wrote:


I'm in the 1%, too.

Perhaps that's because of my OS being Windows and me being a Fossil  
newbie.


Maybe me and my co-workers aren't exemplars of The Average Fossil User  
(current and future) but typing commands in a shell is not our common  
approach to move or delete files.
Reference point are files on a harddrive actually belonging to a  
specific software project which are managed and altered via IDE and file  
browser and afterwards confirmed (not performed) in fossil.


Fossil should not interfere with that worklflow.

I'd prefer that default `rm`/`mv` without options leave my file system  
alone. A `--forcefilesytem` flag would be a convenient enhancement.


personally, I would _not_ like to see a mandatory `--forcefilesystem'  
option in order to get the usually desired behaviour.


otherwise, see the previous mail by jan nijtmans which proposes a very  
sensible solution in my view: create a new alias `forget' for the current  
`rm' (which then should become the sole command performing that sort of  
operation (removing file from `fossil' tracking w/o touching file system)  
in due time -- thr sooner the better ...) and start to use the already  
existing `rename' instead of `mv'. this would ease the way of making rm/mv  
act like they really should (in the view of most people I really would say  
-- and that's an important criterion w.r.t. what a good default behavior  
should be) namely like what is happening in `hg' (I agree with warren  
young that the `hg' people seemingly have thought long enough about this  
and found a good solution and implemented enough options to cover all  
relevant use cases).


another point which has already been made in this thread, but might be  
emphasized: of course `mv' and `rm' already touch the file system quite  
regularly namely on the other end: someone updating from your repository  
(or your remote repo to which you (auto)sync)) after you performed `mv'  
or `rm' will of course modify his checkout (as indeed, it should). it  
makes (usually, but not always I admit) no sense that locally one has to  
go again and again through the routine of mirroring each and every `fossil  
rm' and `fossil mv' by a corresponding file system action. I understand  
that some people _want_ this but there needs would be satisfied if that is  
achieved by `rename/forget' in the future.






-Tontyna

BTW: As soon as I started exploring Fossil I startet developing a GUI  
application to comfortably operate Fossil. My GUI is much alike Paul's  
`fcommit`.


Am 04.03.2015 um 18:24 schrieb paul:

On 03/03/15 22:27, j. van den hoff wrote:


.
so, I would second the OP's request to make fossil behave
essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure
that would be the better behaviour in the overwhelming number of use
cases (i.e. right now I would guess that in 99 out of 100 cases
`fossil mv/rm' is followed by the corresponding os-level command, so
...).


I'm in the 1%.

I prefer _not_ to use the command line. So if I want to move a file or
directory I usually do that with a file browser. Same for deleting.

When I eventually come to doing a check-in, renamed/deleted files show
up in
the missing tab of my fcommit GUI (*), and it's then, using the GUI,  
that I

tell fossil what I've done, and then I commit.

If fossil mv also moves files on a filesystem, I'd be happy with that,
so long
as I can still use a file browser as I'm doing now.

If I want to move a file on my hard drive, I think I should be able to
do it
however I like, whether it's managed by a version control system or not.

Regards,

Paul

(*) www.p-code.org/fcommit


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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Justification for two-step mv and rm

[j. van den hoff]

On Tue, 03 Mar 2015 22:22:40 +0100, Richard Hipp d...@sqlite.org wrote:


On 3/3/15, Warren Young w...@etr-usa.com wrote:
Is there a good reason that “fossil mv” and “fossil rm” must be  
followed by
OS-level mv and rm commands?  I miss the behavior of Subversion which  
made

these into a single step.


When I have suggested changing this, I got push back that the change
will break existing scripts.


IIRC there was a lot of aversion at that time on the list along the line  
fossil should not mess with my file system which I personally found (and  
still find) essentially non-sequitur (since every `fossil up' does of  
course cause changes of the checkout content anyway). I'm also not sure  
what scripts would break and what the amount of work would be to fix those  
scripts (except removing the OS-level `mv' and `rm' actions if those were  
then executed by fossil itself) in comparison to getting an overall  
preferable behaviour (in my view, anyway). so, I would second the OP's  
request to make fossil behave essentially like svn (or hg) regarding `mv'  
and `rm'. I'm quite sure that would be the better behaviour in the  
overwhelming number of use cases (i.e. right now I would guess that in 99  
out of 100 cases `fossil mv/rm' is followed by the corresponding os-level  
command, so ...).








--
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] SQLITE_ERROR: no such function: score

[j. van den hoff]

On Mon, 02 Mar 2015 22:16:40 +0100, jungle Boogie  
jungleboog...@gmail.com wrote:



Hi j. van den hoff,
On 2 March 2015 at 12:54, j. van den hoff veedeeh...@googlemail.com  
wrote:

something seems broken, currently (or what am I missing?):

issuing `fossil search something' yields

SQLITE_ERROR: no such function: score
fossil: no such function: score: {INSERT INTO  
srch(rid,uuid,date,comment,x)

SELECT blob.rid, uuid, datetime(event.mtime),
coalesce(ecomment,comment),  score(coalesce(ecomment,comment))  
AS y

FROM event, blobWHERE blob.rid=event.objid AND y0;}

happens with fossil version 1.31 [14302b6cc7] 2015-03-02 05:54:14 UTC

under macos 10.9.5.



See this post by me about fossil search from last month:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19060.html


yes, same problem. but now reply to your post in the archive (and thus no  
solution) it seems, no?





thx/joerg



---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
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