Thus said Ron Aaron on Thu, 06 Mar 2014 06:48:45 +0200:
Does this mean something to someone? It's as though stunnel is trying
to set a socket option on stdout or something... any help with this
would be appreciated, I'm surely not the only person with this issue.
Can you share your
Thus said Ron Aaron on Thu, 06 Mar 2014 16:54:41 +0200:
The attached zip has the conf file as well as the log.
The stunnel.conf that you sent worked just fine for me. I was able to
successfully clone. At what point in your setup do you see the stunnel
errors? What version of stunnel?
Hello,
Is there any interest in testing and merging in the changes I made on
the http-auth branch?
It's fairly functional at the moment and as far as I know there are not
any problems.
The changes include:
1) Automatically prompt for HTTP Basic Auth when receiving a 401 in a
Thus said Richard Hipp on Tue, 11 Mar 2014 10:32:23 -0400:
I think I've seen this too. It might be a bug in fossil stash.
It does appear to be so, however, I'm not certain what the best fix is.
How about:
http://www.fossil-scm.org/index.html/info/c2d748ae2c
Or would it be better just to make
Thus said Michael Weise on Fri, 14 Mar 2014 11:03:20 +0100:
Doesn't fossil store the password for future use?
fossil version?
Andy
--
TAI64 timestamp: 4000532314e6
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
Thus said Andy Goth on Mon, 24 Mar 2014 17:14:58 -0500:
At present, the only way to distinguish between files and directories in
flat view is to check whether their link URL goes to dir or finfo.
Will this work?
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg13816.html
Thus said Mallik Abhinas on Wed, 26 Mar 2014 16:25:17 -:
And I want it to be changed to 80, I want my website to run in 80 port
not on 8080.
You should be able to get some ideas about how to set this up from the
following:
http://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki
Hello,
Some of the tickets I submit have long lines in them, mainly due to
base64 encoded data. In these tickets, the summary ends up far to the
right of the browser and require scrolling to see. I don't mind the long
lines in the comment, but is there any way to keep the summary in
Thus said Andreas Kupries on Mon, 31 Mar 2014 08:48:16 -0700:
That should be configurable in the HTML setup of the view page, i.e.
repo/tktsetup_viewpage
Generally look at
repo/tktsetup
Thanks, I'll take a look at these pages and see if I can get them to
work out.
Andy
--
Thus said Andy Goth on Wed, 02 Apr 2014 18:05:24 -0500:
The highlighting in most lines of this diff is confusing, and I don't
think I can explain it fully. You'll just have to see for yourself.
Indeed, there are numerous cases of something being highlighted as a
change even though it's
Thus said Andy Goth on Wed, 02 Apr 2014 20:52:04 -0500:
For unified and side-by-side diffs, I'd like the option to show the
entire file in addition to the current behavior of showing only a
limited context surrounding the changes.
Maybe I misunderstand your intention, but while
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
When the UUID is abbreviated to three characters, no artifact is
found.
When the UUID is abbreviated to one or two characters, the ambiguous
artifact page is bypassed, and it always seems to link to a ticket.
This explains part
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
When the UUID is abbreviated to one or two characters, the ambiguous
artifact page is bypassed, and it always seems to link to a ticket.
This explains why it always links to a ticket once you get to ``4e'' and
just ``4'' for the UUID:
Thus said Jan Nijtmans on Thu, 03 Apr 2014 09:06:30 +0200:
Fixed here:
www.fossil-scm.org/index.html/info/c23190a61d
Looks good!
Thanks,
Andy
--
TAI64 timestamp: 4000533d73db
___
fossil-users mailing list
Thus said Martin Gagnon on Sat, 05 Apr 2014 10:55:58 -0400:
http://www.fossil-scm.org/index.html/timeline?y=ci
The checkin from 2014-04-04 10:20 get a merge that look to come from
nowhere. (I've tried to follow the line with n=2000)
It looks normal to me. Specifically it looks like
Thus said Andy Goth on Thu, 03 Apr 2014 13:07:44 -0500:
Thus said Andy Goth on Wed, 02 Apr 2014 21:37:35 -0500:
When the UUID is abbreviated to one or two characters, the
ambiguous artifact page is bypassed, and it always seems to link to
a ticket.
Thus said Kai Lauterbach on Sun, 06 Apr 2014 12:52:24 +0200:
klaute@dev:AmbiControllerRemote$ fossil push
http://klaute:password@pi:8193;
Round-trips: 2 Artifacts sent: 4 received: 0
Push finished with 5629 bytes sent, 606 bytes received
This should have prompted you to remember the
Thus said Andy Goth on Mon, 07 Apr 2014 14:33:10 -0500:
Those look fine, but did you really intend to reject all requests for
UUID abbreviations shorter than four characters?
Yes, it was intentional. It was not my intention to change the length at
which short UUIDs were supported, only to
Thus said Andy Bradford on 07 Apr 2014 19:59:33 -0600:
It's possible that one of these will collide with a ticket, ticket
change or other blobs... Should these also be subject to the same
test?
By the way, in the event that there is a collision, the blob is
preferred over
Thus said Andy Goth on Mon, 07 Apr 2014 22:43:21 -0500:
I do prefer consistency, but we're going to need to think more about
whether we want to break something which used to work just for the
sake of consistency.
I'm leaning more towards the thought that this didn't really work well
Thus said Stephan Beal on Tue, 08 Apr 2014 16:58:00 +0200:
AFAIR the point of collisions with Events has never been
mentioned/pointed out before. i, for one, would be all for the UUID
resolution treating events equally, _but_ that opens up potential new
UUID ambiguities
Hello,
It isn't possible to do fossil sync/pull/push --once anymore after
cloning a repository if the Fossil user does not match the local user
due to this change:
http://www.fossil-scm.org/index.html/info/64aa75260f48781c
This is what happens...
Here, the new URL is properly parsed
Thus said Stephan Beal on Thu, 10 Apr 2014 15:51:31 +0200:
IIRC the original problem was that the user name was not being
remember for normal use cases. That particular change has been in
place since October with no problem reports except for this corner
case (i didn't even
Thus said Stephan Beal on Sun, 13 Apr 2014 17:54:49 +0200:
question: would this need fixing?
I think at the very least it should be possible to unset a user that was
configured as a default via ``fossil user default user''; perhaps a
``fossil user undefault'' which executes:
DELETE FROM
Thus said j. van den hoff on Sun, 13 Apr 2014 18:37:56 +0200:
only after your and stephan's responses I realize that `default-user'
is _not_ initialized at the time of repo creation/opening but indeed
only via `fossil user default somename'.
It is correct that when you first clone, Fossil
Thus said David Given on Mon, 14 Apr 2014 22:28:07 +0100:
It might also be useful to add:
# (To abort the commit, leave this file unchanged)
I was about to point out that this wouldn't be a good idea when using
merge --cherrypick because it actually automatically includes the
Thus said Andy Bradford on Mon, 14 Apr 2014 21:40:00 -0600:
... but apparently Fossil is smart enough to figure out that even with
an uncommented line in the commit message, it still treats it as an
empty message unless you alter it!
Correction, unchanged, not empty.
Andy
--
TAI64
Thus said Matt Welland on Fri, 18 Apr 2014 08:52:09 -0700:
Round-trips: 1 Artifacts sent: 0 received: 0 Round-trips: 1
Artifacts sent: 0 received: 109 Round-trips: 2
Artifacts sent: 0 received: 109 Round-trips: 2
Artifacts sent: 0 received: 773 Round-trips: 3
Artifacts sent: 0 received: 773
Thus said Matt Welland on Fri, 18 Apr 2014 10:32:26 -0700:
Could it be an OS dependency? I'm on SuSe Linux (SLES11).
No, I can reproduce it on OpenBSD. I'm looking at it more closely to see
what might be causing it. Basically, you need a long commit in progress
and then try to sync. I can
Thus said Matt Welland on Fri, 18 Apr 2014 10:41:39 -0700:
How big is the repo? The one I'm cloning is 420 MB. Perhaps that is a
factor?
No, the problem appears to be the difference between using test-http and
http as the remote command. The default behavior for the Fossil client
is to send
Thus said Andy Bradford on 18 Apr 2014 18:56:09 -0600:
Everything works as expected (e.g. no locking issues).
I spoke too soon. If I give the Fossil user permissions (e.g. don't
clone as nobody) then the issue arises again.
It doesn't appear to be isolated to just SSH. I can cause
Thus said Richard Hipp on Thu, 17 Apr 2014 11:13:38 -0400:
Would this really require a big change? Seems like about all you have
to do is COMMIT after each round-trip to the server, rather than
waiting to COMMIT at the very end. Or, just COMMIT instead of ROLLBACK
after getting a
Thus said Andy Goth on Sat, 19 Apr 2014 16:38:44 -0500:
$ fossil http
GET /timeline
Works for me:
$ ../fossil http
GET /timeline
...
This page was generated in about
0.011s by
Fossil version [53aea235fa] 2014-04-15 09:40:49
/div
/body/html
Also works for HTTP/1.1. I see we're using the
Thus said Andy Goth on Sat, 19 Apr 2014 17:12:04 -0500:
Well, I do have $SSH_CONNECTION set due to having logged in via ssh.
Yes, and ``fossil http'' reads that variable to determine what IP
address the SSH client is coming from. Perhaps there is a better way or
at least there might be
Thus said Matt Welland on Wed, 16 Apr 2014 09:01:28 -0700:
fossil commit cfgdat tests -m Added another drc test
Autosync: ssh://host/path/project.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: database is locked: {UPDATE event SET mtime=(SELECT
m1 FROM
Thus said Matt Welland on Wed, 16 Apr 2014 09:01:28 -0700:
Autosync: ssh://host/path/project.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: database is locked: {UPDATE event SET mtime=(SELECT
m1 FROM time_fudge WHERE mid=objid) WHERE objid IN (SELECT mid FROM
Thus said Matt Welland on Mon, 21 Apr 2014 09:26:25 -0700:
Yes! This is fixed on latest! Any idea which commit fixes the problem?
Will you tell me exactly which version of fossil it is? e.g. run
``fossil version'' with the fossil binary that exhibits the problem on
the server.
Thus said Matt Welland on Mon, 21 Apr 2014 09:26:25 -0700:
Yes! This is fixed on latest! Any idea which commit fixes the problem?
I ran fossil bisect to figure out where the fix came into trunk [I must
say, this is the first time I've used fossil bisect and it was quite
handy!]. Here is
Thus said Samuel Debionne on Tue, 22 Apr 2014 11:36:46 +0200:
Here is a sequence I'm doing several times a day for years and that did
not work this morning :
fossil commit -m Blabla from my PC
fossil update from my Mac
Has a fork happened? Have a look at the timeline
Hello,
As of [2aaae64a59] compiling Fossil on OpenBSD results in a warning:
bld/name.o(.text+0x11a): In function `test_ambiguous_cmd':
./src/name.c:742: warning: strcpy() is almost always misused, please use
strlcpy()
Is this something to be concerned about for Fossil? I know there are
Thus said Stephan Beal on Tue, 22 Apr 2014 18:07:08 +0200:
Just to confirm that: this has come up several times before in the
past year and, so far, has remained unexplained. We're not sure what
causes it or how to reproduce it. (At least i don't remember seeing
any commits/posts
Thus said Matt Welland on Tue, 22 Apr 2014 22:22:16 -0700:
This has happened enough that I'm sure it was a real issue but it has
been long enough since anyone reported it to me that I'd assumed it
was fixed.
Unfortunately, nobody has been able to reproduce so it's kind of hard to
fix. The
Thus said Eduardo Morras on Wed, 23 Apr 2014 08:49:52 +0200:
Don't know, but strlcpy() exists only in *BSD libc, but no in
GNU/Linux glibc or Windows.
Sure enough, guess I should RTFM a bit more. I looks like this isn't
exactly an option then, and the strlcpy() that are used in
Thus said Richard Hipp on Wed, 23 Apr 2014 14:19:44 -0400:
QUESTION: What do I call the hyperlink that shows annotate/blame
only forwards in time instead of backwards in time.
Could it be considered commit trail?
Andy
--
TAI64 timestamp: 40005358400e
Thus said Michai Ramakers on Wed, 23 Apr 2014 18:34:32 +0200:
I have no clue on sync logic at all, but perhaps this helps: in all
cases I remember here (3 or so), when sync of commit on host A was not
seen during sync on host B, doing a dummy-commit on host A, then
pulling again on
Thus said Paulus Tuerah on Fri, 25 Apr 2014 06:12:31 -0700:
I'm confused, I clone with user_b and push with user_b, how can
the remote repository use user_a as the committer?
The user that is used to do the sync operation may or may not be the
same user that made the commit in the
Thus said Jan Nijtmans on Thu, 01 May 2014 16:25:18 +0200:
Maybe the idea is good, but the sign of the timezone
correction was wrong, (Just a wild guess! )
I just tested and it's not the sign of the timezone. I created a simple
git repository and then ran through fossil import
Thus said David Given on Thu, 01 May 2014 23:01:50 +0100:
Are you sure that get merged? I remember asking for a sign-off a
couple of times, but never got a response, and eventually abandoned
it.
It actually did get merged:
Thus said Jan Danielsson on Fri, 02 May 2014 17:39:20 +0200:
Artifacts sent: 0 received: 895 Error: Database error: database is locked:
{UPDATE event SET mtime=(SELECT m1 FROM time_fudge WHERE mid=objid) WHERE
objid IN (SELECT mid FROM time_fudge);} #key_3_2
[...]
As you say, it is
Thus said Richard Hipp on Thu, 17 Apr 2014 11:33:59 -0400:
Would that be a valid strategy? Couldn't we end up with a
partial state which we can't work from until the pull finishes to
completion?
The logic (in manifest.c) is designed to be able to deal with partial
state
Thus said Andy Bradford on 04 May 2014 22:44:21 -0600:
What have I missed? Perhaps with the per round-trip commit it is not
really necessary to also have a COMMIT if the network drops that is
implemented in [1317331eed]?
Ok, as it turns out, one potential resolution is to simply
Thus said Rich Neswold on Wed, 16 Apr 2014 15:40:23 -0500:
It would be nice if fossil would break the pull into smaller
transactions which contain valid timeline commits so, if there's a
database timeout, the next time I try to pull it can continue where
it left off.
I've been
Thus said Richard Hipp on Wed, 07 May 2014 07:06:31 -0400:
The purpose of the hooks is to verify that all of the content in the
repository is still accessible. Before each commit, the hooks run to
verify that all of the artifacts can still be un-deltaed and
uncompressed and they
Thus said Richard Hipp on Wed, 07 May 2014 11:02:55 -0400:
We might be talking about different hooks. I'm concerned about the
verify_before_commit hook implemented here:
http://www.fossil-scm.org/fossil/artifact/615e25ed6?ln=94-104
Yes, it does appear that we were talking about
Thus said Jan Nijtmans on Thu, 08 May 2014 12:29:27 +0200:
Well, I went ahead, and merged the proposed change to trunk.
This means that the initial empty commit is no longer created by
surprise, but it's only a change of the default behavior: When
specifying
Thus said Rich Neswold on Thu, 08 May 2014 15:18:43 -0500:
I was thinking of attacking the problem a little higher up (since I'm
way too nervous touching the low-level stuff):
So did I initially, though my first thought was simply to have autosync
try multiple times when failing (in the
Thus said Doug Franklin on Thu, 08 May 2014 23:00:03 -0400:
Does SQLite support nested transactions? If so, that would seem to be
worth considering.
It does appear to support them:
https://www.sqlite.org/lang_transaction.html
Andy
--
TAI64 timestamp: 4000536c46e4
Thus said Stephan Beal on Fri, 09 May 2014 11:16:04 +0200:
So it didn't even attempt to add the file that it said was ADDED.
That's why the R-card is right. The error is the missing F-card.
Please tell me that's not on the trunk?
Yes, it was on trunk, and that's actually how I
Thus said Gerald Gutierrez on Fri, 09 May 2014 15:40:13 -0700:
$ ps auxww | grep fossil
USER PID %CPU %MEM VSZRSS TT STAT STARTED
TIME COMMAND
xxx 7619 0.0 0.2 2490036 29836 ?? S 9:05AM
0:13.80 /usr/local/bin/fossil commit --no-warnings -m
Thus said Gerald Gutierrez on Sat, 10 May 2014 01:53:56 -0700:
frame #8: 0x000105719ba2 fossil`ssl_receive(NotUsed=unavailable,
pContent=unavailable, N=unavailable) + 50 at http_ssl.c:399
396 size_t got;
397 size_t total = 0;
398 while( N0 ){
- 399 got =
Thus said Marty on Tue, 13 May 2014 16:34:29 -0700:
Seems like there's a bug somewhere, but maybe there was an improper
sequence of user events?
Seems like a bug to me.
Here is what I see:
$ fossil merge trunk
MERGE foo.txt
RENAME foo.txt - foobar.txt
fossil undo is available to undo
Thus said Stephan Beal on Wed, 14 May 2014 17:47:43 +0200:
'mv' (for reasons ido not understand) sets
vfile.origname=vfile.pathname where vfile.origname IS NULL (that
caused me a bit of greif in libfossil, as i have to work around it in
several places). i
Thus said Matt Welland on Wed, 14 May 2014 16:08:50 -0700:
I have the same annoyance with scrape 'n paste. Would adding a space
between the [ or ] and the hex string alleviate the annoyance but
still provide the visual delineation?
I think the problem isn't the amount of space between
Thus said Jan Nijtmans on Wed, 14 May 2014 12:11:42 +0200:
Anyway, I would like to execute the same plan (merge branch
no-initial-commit to trunk) once more. If anyone thinks this is a
bad idea (maybe because another bug prevents us to do that), I'm all
ears.
I did some
Hello,
I recently noticed that if I hit /stat on my own repositories it shows
``delete mode'' in the Database Stats, but on www.fossil-scm.org it
shows ``wal mode.'' I assume this is to leverage some of the benefits
listed here:
https://www.sqlite.org/draft/wal.html
I suppose it can
Hello,
I've been using the code for the per-round-trip-commit and while it
seems stable to me, I think it would be good for another pair of eyes to
look at it:
http://www.fossil-scm.org/index.html/vdiff?from=77f53423aec1d2ebto=4cfe13e962a95fe9sbs=1
I think it's ready to merge if folks are
Thus said Jan Nijtmans on Sun, 18 May 2014 21:34:10 +0200:
I think it would result in the possibility (however unlikely) that a
ticket change hook firing is missing. Scenario: Assume a sync is done
containing 2 chunks, the sync of the second chunk fails for whatever
reason. If the first
Thus said Jan Nijtmans on Sun, 18 May 2014 21:34:10 +0200:
Is there anything else it should do? E.g. should the changes in the
autosync-tries branch be merged with it to make autosync try
multiple times to sync? Perhaps the need to have autosync try harder
is minimized if Fossil
Thus said Matt Welland on Sun, 18 May 2014 22:39:57 -0700:
We are still seeing this scenario. User education seems to have
lessened the frequency a little.
Are you still running a version of Fossil that does not have this fix:
Hello,
Does anyone have an example script that I can use for a client-side
ticket change hook?
Thanks,
Andy
--
TAI64 timestamp: 4000537a18e8
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
Thus said Mark Janssen on Mon, 19 May 2014 22:14:24 +0200:
And to complete the picture, this is the actual tkt-hook cgi script I
am currently using:
Thanks for sharing, but I cannot even get the TH1 script to even do
anything. It took me a while before I realized that the
Thus said Jan Nijtmans on Sun, 18 May 2014 21:34:10 +0200:
I would just call manifest_crosslink_end(MC_PERMIT_HOOKS) here, it
means that possibly the hook might fire twice (unless someone has a
better suggestion.) but that's better than the possibility to
mis a change.
You
Thus said Stephan Beal on Wed, 21 May 2014 18:49:21 +0200:
i'll admit to having uninstalled apps which have violated my sense of
propriety, but an extra file in my home dir is not (because of
the Unix history behind it) one of those proprieties. Historical
momentum wins here,
Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400:
I think that's an HTTP thing. In a URL, spaces are encoded as +. So
fossil is doing the right thing in converting + characters in the
URL into spaces.
It certainly handles them correctly when given them, however, there may
be a
Thus said Richard Hipp on Tue, 27 May 2014 16:37:01 -0400:
Candidate fix checked into trunk.
Works here, and much nicer than what I suggested:
Before:
$ printf 'GET /doc/tip/test/test-page%%2b%%2b.wiki HTTP/1.1\r\nHost:
localhost:8080\r\n\r\n' | nc localhost 8080 | grep base
base
Thus said Joel Bruick on Tue, 27 May 2014 21:55:06 -0400:
It's really an HTML form thing [1] that only applies to the query
portion of the URL. In the path component, we technically should be
percent-encoding spaces and leaving any instances of + alone, which
would then allow you to
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x 2 root wheel 512 May 29 15:32 .
-rw-r--r-- 1 ftp ftp3435520 May 29 15:32 f_f
-rw-r--r-- 1 root wheel 3592192 May 29 15:32 r_w
root@main:/tmp/ftmp# f sync r_w -R f_f
When
Hello,
I introduced some code on the autosync-tries branch that causes autosync
to retry if it fails, up to a maximum of 3 tries.
1) Should autosync retry?
2) Should the number of tries be configurable?
I would like to either merge or abandon, but would like some additional
feedback first.
Thus said Richard Hipp on Thu, 29 May 2014 10:53:57 -0400:
In my experience, autosync only fails when WIFI is down (or turned
off). Retries won't help that. It just takes longer to finish.
I agree that for network related failures, retry won't help. Others have
reported non-network related
Thus said Michai Ramakers on Thu, 29 May 2014 17:08:52 +0200:
In case both files as well as their parent-dir are owned ftp.ftp, both
syncs work fine.
Sounds like a simple case of permissions problems to me. The user that
is running the sync must have sufficient Unix filesystem privileges
Thus said Stephan Beal on Thu, 29 May 2014 17:12:35 +0200:
i = setgid(sStat.st_gid);
i = i || setuid(sStat.st_uid);
sure enough. It switches back to the owning user/group of the repo.
IMO, that's not a bug, just an unfortunate side effect of your setup.
In fact, it's intended
Thus said Michai Ramakers on Thu, 29 May 2014 17:22:08 +0200:
Alright, thanks for looking into this (, all). Does this also explain
my last mail (in case one file is owned root.wheel, and the other file
and parent-dir are owned ftp.ftp, all works fine)?
I may have mispoken earlier. Fossil
Thus said Stephan Beal on Thu, 29 May 2014 18:06:49 +0200:
That could also (more simply, i think) be interpreted as:
0 == off
1+ == number of times to try
I'm a bit confused, however, in how 0 and 1 should be interpreted...
Given that Fossil currently does 1 autosync attempt: Does 0
Thus said Stephan Beal on Thu, 29 May 2014 21:44:12 +0200:
0 means no autosync, 1 means one attempt (same as now), 2+ means retry
N times. But because there really is no difference between try and
retry, 1+ is the same logic:
I assume we're talking about a different setting than the
Thus said Stephan Beal on Thu, 29 May 2014 22:10:24 +0200:
Wasn't even aware of pull-only until earlier today. i am completely
ambivalent on the topic - never had any problems with autosync - this
was just what came to mind when you posted. Seemed easier than adding
a new option, but was
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
Round-trips: 1 Artifacts sent: 0
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
Can anyone tell what happens under the hood here..?
Bingo:
http://www.fossil-scm.org/index.html/artifact/d1aef141c961172a1a32f619f339c641cdeaa674?ln=259,268
So it does indeed call ``fossil http'' which will cause fossil to chroot
Thus said Ron Wilson on Fri, 30 May 2014 09:42:44 -0400:
As I recall, the 2 options have slightly different affects.
pull-only only affects auto sync, while dont-push affects both
manual and auto sync. A manual push will, of course, still push.
``pull-only'' pertains only to
Thus said Michai Ramakers on Fri, 30 May 2014 21:06:36 +0200:
michai@main:~/proj/081/adm$ f ci -m 'added note about spent time'
time_spent.txt
New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0
working checkout does not match what would have ended up in the
repository:
Thus said Stephan Beal on Fri, 30 May 2014 22:25:30 +0200:
H. It seems fossil no longer has an option to create the initial
checkin.
It does using the --date-override option:
fossil new --date-override '2014-05-30 00:00:00' test.fossil
Will create a new fossil with an initial empty
Thus said Stephan Beal on Sat, 31 May 2014 16:33:48 +0200:
i would personally like to see it kept (mainly for future
compatibility with libfossil, which doesn't require an initial checkin
;), but not as the default. The default should stay as it historically
has been - creating
Thus said Stephan Beal on Sat, 31 May 2014 18:49:09 +0200:
Am i wrong, or did Joel's patch just correct the problem:
Yes, it does appear to correct it:
$ ../fossil ver
This is fossil version 1.29 [1a0179abd7] 2014-05-31 16:37:06 UTC
$ ../fossil info | grep checkins
checkins: 0
$ jot -w
Thus said Abilio Marques on Sat, 31 May 2014 00:12:00 -0430:
Let's say I want to do this setup:
Clone sqlite repo on a local server
Then clone the server into several machines, with the users pushing
changes
Are they committing changes to trunk?
Then, someday, I will want to update my
Thus said =?UTF-8?B?RMO2bcO2dMO2ciBHdWx5w6Fz?= on Sun, 01 Jun 2014 12:56:41
+0200:
An interesting scenario, what is there to be learned from it for
fossil? Since fossil doesn't like history rewrites, are we protected
to some degree from falsified commits?
With our without PGP
Thus said B Harder on Sun, 01 Jun 2014 22:42:39 -0700:
I think drh unnecessarily missed an opportunity there. He seemed to
work harder to obfuscate what fossil actually was than giving a single
passing description and moving on with his talk about SQL and using
fossil by name where it's
Thus said Nico Williams on Tue, 03 Jun 2014 11:42:44 -0500:
- the date (Fossil changes the timezone to +, that is, it loses
the timezone of the original).
Timestamps in Git are UTC and have no timezone offset. There may be
additional metadata associated with a commit that records
Thus said Stephan Beal on Tue, 03 Jun 2014 19:14:20 +0200:
iso8601 == julian tests...
Running all event.mtimes through the julian==iso converters...
1645 Julian timestamps tested from event.mtime.
4 record(s) (0.24%) differed round-trip by 1ms (this is normal/not
unexpected).
Awesome! Time
Thus said Nico Williams on Tue, 03 Jun 2014 15:49:19 -0500:
- the ability to commit with timestamps other than now, arbitrary
committer info, ...
Fossil has both --user-override and --date-override when doing a
checkin.
- metadata for referring to an original commit (so that one
Thus said Stephan Beal on Tue, 03 Jun 2014 23:15:38 +0200:
Based on that description, that sounds doable, but i'm inherently
dubious of rebase because i've broken my git repos more than once
when using it.
Isn't rebase effecitvely merge from trunk (or any other branch) into a
branch?
Thus said Richard Hipp on Tue, 03 Jun 2014 18:04:22 -0400:
It does look like timeline does not display/represent the
relationship of the Q-card.
It does not at this time. Can you suggest a look for how cherrypick
merges should appear on the timeline?
I'm not sure... A
201 - 300 of 969 matches
Mail list logo
