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
--- 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 1
ot; 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&
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
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
patch for `fossil help uv' output:
11,12c11,12
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 equivalen
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
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, *
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
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
gue 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 plann
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 o
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
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 c
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 prom
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
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
Data
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
subsc
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 revolutionar
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
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 ver
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 $(...)
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 (s
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
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 vie
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 abo
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 impor
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...
On Wed, 23 Aug 2017 22:28:03 +0200, Richard Hipp wrote:
On 8/23/17, j. van den hoff wrote:
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
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 revolut
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 t
On Wed, 23 Aug 2017 17:14:05 +0200, Warren Young
wrote:
On Aug 23, 2017, at 7:21 AM, Richard Hipp wrote:
On 8/23/17, j. van den hoff 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
On Wed, 23 Aug 2017 15:21:46 +0200, Richard Hipp wrote:
On 8/23/17, j. van den hoff 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
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
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
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 lik
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
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 fil
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
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 ar
On Sun, 14 Feb 2016 13:10:49 +0100, Scott Robison
wrote:
On Sun, Feb 14, 2016 at 4:22 AM, j. van den hoff
wrote:
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&
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 pr
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
On Wed, 02 Dec 2015 13:01:42 +0100, Richard Hipp wrote:
On 12/2/15, j. van den hoff 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
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
On Wed, 02 Dec 2015 11:54:06 +0100, Richard Hipp wrote:
On 12/2/15, j. van den hoff 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
On Wed, 02 Dec 2015 10:51:08 +0100, Richard Hipp wrote:
On 12/2/15, j. van den hoff wrote:
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?
The --verily optio
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
On Mon, 23 Nov 2015 22:04:07 +0100, Richard Hipp wrote:
On 11/23/15, j. van den hoff wrote:
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.
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.
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
On Mon, 23 Nov 2015 20:13:40 +0100, Warren Young wrote:
On Nov 23, 2015, at 9:42 AM, j. van den hoff
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
On Mon, 23 Nov 2015 16:10:02 +0100, Warren Young wrote:
On Nov 22, 2015, at 6:47 AM, j. van den hoff
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 colle
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. con
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 memor
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
On Thu, 10 Sep 2015 20:16:52 +0200, Martin Gagnon 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
conve
On Thu, 10 Sep 2015 16:54:30 +0200, Martin Gagnon 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
wrote:
> On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal
> wrote:
>
>> On Wed, Sep 9, 2015 at 1
On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal
wrote:
On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein
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
functional
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 "timelin
On Mon, 17 Aug 2015 18:04:37 +0200, 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 fossi
On Tue, 14 Jul 2015 07:05:05 +0200, Christopher M. Fuhrman
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 $ t
On Tue, 14 Jul 2015 06:50:57 +0200, Christopher M. Fuhrman
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
On Fri, 19 Jun 2015 16:40:51 +0200, Stephan Beal
wrote:
On Fri, Jun 19, 2015 at 4:37 PM, Andy Gibbs
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 l
On Sat, 13 Jun 2015 13:43:30 +0200, Martin Gagnon 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 th
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/mai
On Fri, 29 May 2015 17:38:39 +0200, Richard Hipp wrote:
On 5/29/15, Matt Welland 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 yo
On Thu, 28 May 2015 23:29:14 +0200, j. van den hoff
wrote:
On Thu, 28 May 2015 23:14:30 +0200, Ron W wrote:
On Thu, May 28, 2015 at 5:09 PM, j. van den hoff
wrote:
On Thu, 28 May 2015 22:47:32 +0200, Ron W wrote:
"graft" ?
used by mercurial for our `merge --cher
On Thu, 28 May 2015 22:21:19 +0200, Ron W wrote:
On Thu, May 28, 2015 at 2:56 PM, Andy Bradford
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")
On Wed, 27 May 2015 19:24:38 +0200, Ron W 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
wrote:
the "request to work on branch" is the catch: he wan
On Wed, 27 May 2015 18:49:46 +0200, David Mason 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 colle
On Wed, 27 May 2015 18:05:15 +0200, Andy Bradford
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
On Wed, 27 May 2015 13:25:43 +0200, Richard Hipp wrote:
On 5/27/15, j. van den hoff 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
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 bra
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 me
On Fri, 08 May 2015 21:14:07 +0200, Abilio Marques
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,
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 l
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
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-for
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
wrote:
I lost track of what exactly has happened w.r.t. to the previously
variable-length sha1 reporting (to
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 wrap
On Sun, 26 Apr 2015 19:51:44 +0200, Matt Welland
wrote:
I like this idea. I will test this branch Monday.
+1
On Sun, Apr 26, 2015 at 10:16 AM, Jan Nijtmans
wrote:
2015-04-26 12:54 GMT+02:00 Richard Hipp :
> Yes, but it is not a fork. And so we shouldn't call it "fossil forks"
> since th
On Sat, 25 Apr 2015 03:03:50 +0200, Andy Bradford
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
On Tue, 21 Apr 2015 11:09:05 +0200, Jan Nijtmans
wrote:
2015-04-21 10:24 GMT+02:00 Michael Richter :
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 behaviou
On Mon, 20 Apr 2015 23:00:57 +0200, Warren Young wrote:
On Apr 20, 2015, at 1:43 PM, j. van den hoff
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
On Mon, 20 Apr 2015 22:10:31 +0200, jungle Boogie
wrote:
Hello,
On 20 April 2015 at 12:43, j. van den hoff
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
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
On Sat, 18 Apr 2015 15:53:53 +0200, Richard Hipp 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 f
On Fri, 17 Apr 2015 06:56:13 +0200, Andy Bradford
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
On Thu, 16 Apr 2015 22:58:55 +0200, Ron W wrote:
On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison
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
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 similar
On Fri, 27 Mar 2015 21:15:58 +0100, Andy Bradford
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
On Fri, 27 Mar 2015 21:13:47 +0100, Andy Bradford
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
ng. 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 wrote:
hi list,
I have encountered a strange behaviour (of course right now
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
On Tue, 17 Mar 2015 17:06:33 +0100, Ramon Ribó
wrote:
fossil version
This is fossil version 1.32 [302052d30b] 2015-02-20 08:30:51 UTC
fossil sync
Usage: c:\other\binutils\fossil.exe sync URL
is it not possible to use "sync" without URL?
yes, if you have defined a remote URL via `fossil re
On Sat, 14 Mar 2015 10:18:35 +0100, Stephan Beal
wrote:
On Sat, Mar 14, 2015 at 5:05 AM, Richard Hipp 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 o
rresponding 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
1 - 100 of 352 matches
Mail list logo