Thus said Sean Woods on Fri, 01 Aug 2014 14:17:22 -0400:
I forget where I put it! I usually put that in ~/fossils but it's not
there. Is there a way I can tell, looking at the checkout, where the
repository actually is (the local one, that is)?
If you are in an open repository you can just
Thus said Sean Woods on Fri, 01 Aug 2014 15:14:42 -0400:
I checked 5-10 and they are all there. Should I check all of them?
Perhaps not. It might be better to focus on what we can know. Do you
know the UUID of the artifacts which are in your local client that you
expect to be on the
Thus said Sean Woods on Fri, 01 Aug 2014 15:16:09 -0400:
swoods@sachem:~/code/pr$ fossil remote
http://swo...@code.seanwoods.com/pr.fossil.cgi
Does the artifact actually exist if you take the UUID of the missing
artifact and ask /info about it via the server URL?
Something like:
Thus said Ron W on Tue, 29 Jul 2014 12:25:08 -0400:
Making autosync default to pull-only would not impact minimize
unintentional forks.
Actually, it would. Consider this scenario.
Tizio clones and uses default autosync.
Caglio clones and enabled pull-only.
Tizio commits something.
Thus said Stephan Beal on Mon, 28 Jul 2014 23:27:04 +0200:
(BTW: is --static preferred or not nowadays?)
I prefer to use --static when fossil is going to be in a chrooted
environment to minimize dependencies, but typically I use it without
--static for daily use.
Andy
--
TAI64
Thus said Baruch Burstein on Sun, 27 Jul 2014 23:31:17 +0300:
When cloning a repository, if I don't have write privileges, can
autosync by default be set to pullonly in the clone, to prevent
annoying pull only - not authorized to push?
Are you suggesting that the clone detect
Thus said Gour on Sat, 26 Jul 2014 13:18:59 +0200:
Maybe fossil's ui should be able to do the same?
It can. Run ``fossil ui'' and browse to Admin-Settings
Andy
--
TAI64 timestamp: 400053d3ce0e
___
fossil-users mailing list
Thus said Joe Mistachkin on Sun, 20 Jul 2014 11:11:08 -0700:
I'm looking for some feedback and/or suggestions on how to improve it.
I imagine this is mostly useful for long commit comments that are broken
up with multiple lines and perhaps other ASCII formatting (like spaces)?
I tried it and
Thus said Michai Ramakers on Thu, 24 Jul 2014 00:04:18 +0200:
(This is really just toying, not a serious setup, but perhaps an
example of a bad or high-latency link.)
Or a proxy tampering with your traffic. Try cloning the Fossil
repository via SSL instead as a test:
fossil
Thus said Andy Bradford on 12 Jul 2014 13:36:58 -0600:
2) The artifact rid was in the unclustered table, but when
create_cluster() ran it prematurely removed it from the table.
I have been able to successfully reproduce/cause this. When a large
number of artifacts are being
Thus said Michai Ramakers on Tue, 22 Jul 2014 12:35:03 +0200:
I can't seem to reproduce what you describe - either that, or I'm
missing the point (did you mean 'merge' as in 'fossil merge'?). I'm
assuming you left out 'fossil add' (or 'addremove') twice in your
example.
Yes, I
Thus said Michai Ramakers on Tue, 22 Jul 2014 17:58:24 +0200:
I don't / didn't use branches other than trunk (which still breaks,
using your example - good).
Yes, this should work with trunk as long as there are no commits that
follow the one which caused the exclusion of artifacts from
Thus said Stephan Beal on Tue, 22 Jul 2014 19:01:27 +0200:
One would think i'd be more conscious of how i throw around byte vs
character :/. i'm still not clear on the whole char-vs-code point bit,
though.
The whole char-vs-codepoint has always been unclear for me, no matter
how many
Thus said Stephan Beal on Sun, 20 Jul 2014 14:03:12 +0200:
fossil commit -m ... --delta
Excellent! I always wondered how to turn on delta manifests. Does this
turn it on for the entire repo, or just the files in the commit?
Thanks,
Andy
--
TAI64 timestamp: 400053cbde68
Thus said Jan Nijtmans on Fri, 18 Jul 2014 23:58:09 +0200:
I interpret this message as:
http://fossil-scm.org/index.html/info/2b79c600d5
And to cover the corner-case, please consider:
http://www.fossil-scm.org/index.html/info/d1b5fd8738e
$ f stat
repository: /tmp/test/../test.fossil
Thus said Ron W on Sat, 19 Jul 2014 14:12:32 -0400:
I think that if a branch from a closed branch feature is going to be
added, it should be exactly that and not a back door on closed
leafs.
This raises the question of just what the intended use of a ``closed
leaf'' is supposed to
Thus said Warren Young on Fri, 18 Jul 2014 09:25:12 -0600:
The DB is on a local ext3 filesystem, so there shouldn't be anything
going on related to non-POSIX semantics.
Is the repository that the server is serving up an actual file, or is it
a link of some kind?
Andy
--
TAI64 timestamp:
Thus said Matt Welland on Fri, 18 Jul 2014 12:41:55 -0700:
Personally I see limited usefulness in closing a leaf. It is branches
that need to be closed (albeit by closing a leaf).
I think this brings up a fine distinction. The behavior of disallowing a
descendent checkin applies to a leaf,
Thus said Warren Young on Fri, 18 Jul 2014 13:58:38 -0600:
It doesn't completely fail. The checkins do occur; fossil just gripes
about it. (This might be the autosync retry feature at work.)
No, autosync only tries once by default in each direction
(pull/push)---the same as it
Thus said Jan Nijtmans on Fri, 18 Jul 2014 23:58:09 +0200:
I interpret this message as:
http://fossil-scm.org/index.html/info/2b79c600d5
What if I do:
fossil up closedbranchname
fossil ci --branch closedbranchname
Andy
--
TAI64 timestamp: 400053c99bca
Thus said Jan Nijtmans on Thu, 17 Jul 2014 23:29:44 +0200:
This was discussed in sept '13 on the fossil-dev mailing list,
title Fossil sync problem: attachments to tickets. Below Richard's
explanation. Good that my memory is not that bad yet, I wouldn't be
able to find this out
Thus said Philip Bennefall on Tue, 15 Jul 2014 21:34:57 +0200:
I got a segfault, which I can reproduce consistently.
Thanks, here's a backtrace:
Starting program: /home/amb/download/tarballs/fossil/fossil /vpatch
Program received signal SIGSEGV, Segmentation fault.
functionSearch
Thus said Philip Bennefall on Tue, 15 Jul 2014 21:34:57 +0200:
fossil /vpatch
I got a segfault, which I can reproduce consistently.
This is not limited to /vpatch. It appears that any of the web page URIs
that are called as command line arguments cause it:
$ fossil /info
Segmentation fault
[self-reply]
Is this also potentially an SQLITE3 bug. Why didn't any of these
functions check db for NULL before passing it on down? Finally
functionSearch gets pHash which is wrong (0x140 is not accessible in my
debugger):
(gdb) list
90056 h =
Thus said Richard Hipp on Wed, 16 Jul 2014 00:05:44 -0400:
I don't know why webpages were ever callable from the command-line in
the first place. This probably has something to do with the help
system, but I'm busy with other things right now and don't have time
to track it down.
It
Hello,
I've been trying to investigate the problem that has been reported over
time and so far I haven't been able to reproduce it or come to any
conclusive decision regarding what might be the cause. When (in Fossil
versions) did this problem first get noticed or start happening?
Thus said Andy Goth on Thu, 10 Jul 2014 15:14:07 -0500:
Not all cherrypicks and backouts are done by [fossil merge]. Around
here, lots of things are done by hand.
I see what you mean. You're looking for a way to tag something as
``merged'' by copy-paste and not using merge
Thus said Stephan Beal on Fri, 11 Jul 2014 00:22:52 +0200:
If that summary indeed reflects the goal, i _think_ it's just a matter
of changing the timeline query to do so. Looking at the code now, i
see that graph.c is quite a bit more than a timeline parser, though,
so maybe it's not as
Thus said Andy Goth on Wed, 09 Jul 2014 18:49:45 -0500:
What's going on here? Everything is tagged trunk, yet [b4a53ba45f] is
displayed as if on a branch. Was there a fork or something?
As Richard already explained it was a fork. For a good explanation of a
fork (which is really just like
Hello,
I have some Tcl scripts (for IRC) that previously had no problems when I
committed. They don't have UTF-8 characters at all, but when I try to
commit them I get the warning:
./test.tcl contains invalid UTF-8. Use --no-warnings or the encoding-glob
setting to disable this warning.
Thus said Jan Nijtmans on Tue, 08 Jul 2014 21:35:07 +0200:
If you don't want this warning, just set 'encoding-glob' to '*'.
I might actually want encoding warnings though...
But did you ever view this file in the fossil UI?
Did the è really look like è there?
I did not, however, if I
Thus said Stephan Beal on Tue, 08 Jul 2014 21:37:50 +0200:
No characters between 128 and 255 are valid UTF-8, to avoid confusion
with the many encodings which use that range.
If no characters between 128 and 255 are valid UTF-8, and they can never
be valid UTF-8 characters, and are used by
Thus said Scott Robison on Tue, 08 Jul 2014 15:48:05 -0600:
The warning you are seeing is that the stream is invalid UTF-8. 0xE8
byte could be an extended ASCII character from one of the ISO-8859-X
code pages. Or it could be real binary data that just happens to
mostly have ASCII text
Thus said Stephan Beal on Tue, 08 Jul 2014 23:50:40 +0200:
Interesting question/option, but i have no answer. Something to
possibly consider?
Or perhaps just making the documentation more clear that all files must
be valid UTF-8. There is already an option to control how encodings are
Thus said Donny Ward on Mon, 07 Jul 2014 12:56:03 -0700:
His reponse in that link:
The pull and sync are requesting and receiving all SHUN records.
I'm not sure that this is what is happening in this case. The
--httptrace output only showed 3 gimme cards requested and none of
Thus said Andy Bradford on 07 Jul 2014 14:40:51 -0600:
I'm not sure that this is what is happening in this case. The
--httptrace output only showed 3 gimme cards requested and none of them
are on the SHUN list.
Ok, apparently the --httptrace that was sent was not representative
Thus said B Harder on Sun, 06 Jul 2014 14:40:58 -0700:
myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1 Artifacts sent: 0 received: 74
Pull finished with 442 bytes sent, 2645 bytes received
myhost$ fossil pull http://joeb...@fossil-scm.org --http-trace
Thus said B Harder on Sun, 06 Jul 2014 14:40:58 -0700:
myhost$ fossil pull http://joeb...@fossil-scm.org --http-trace
Round-trips: 1 Artifacts sent: 0 received: 0
Pull finished with 424 bytes sent, 612 bytes received
It seems that I gave you the wrong option. Please try:
fossil pull
Thus said Andy Goth on Fri, 27 Jun 2014 16:40:33 -0500:
How come events are always shown with (at least) sixteen digits on the
timeline whereas other artifacts are given ten digits?
Perhaps because prior to [49467d2a494] short events that collided with
other types of artifacts were silently
Thus said Andy Goth on Thu, 26 Jun 2014 19:25:05 -0500:
[fossil pull -R repos] prints Usage: fossil pull URL when the
repository doesn't have a known remote URL. I believe the problem is
on line 147 of sync.c in the current Fossil version
Do you mean that the Usage statement should
Thus said Donny Ward on Sat, 21 Jun 2014 17:29:07 -0700:
I have two versions of my repository that I've saved from a while ago,
the last time I ran into this syncing issue. I've linked them both
here, hoping that someone can analyze them and figure out what the
issue is.
Ok, the
Thus said Andy Bradford on 24 Jun 2014 00:21:23 -0600:
If I understand this correctly, it will delete from the unclustered
table but leave behind any newly added cluster artifacts that were
just created. But what about phantoms that might exist in the
unclustered table
Thus said Andy Bradford on 24 Jun 2014 00:39:20 -0600:
Perhaps the cluster rotation mechanism is rotating out clusters faster
than clients are able to consume them in this scenario? So clients
that update infrequently will miss some clusters which will exist in
the unclustered table
Thus said Richard Hipp on Tue, 24 Jun 2014 16:27:08 -0400:
It might be possible to provide an option to disable this checksum
step for large repos.
Would this be different from the repo-cksum setting?
fossil settings repo-cksum
Thanks,
Andy
--
TAI64 timestamp: 400053a9eb67
Thus said Andy Goth on Tue, 24 Jun 2014 15:12:37 -0500:
I'm having trouble with each commit taking about 45 seconds in a
new repository I initially populated with 5154 files totaling 425
megabytes. At this point, there are only five or six commits.
I generated a repository with
Thus said Donny Ward on Sat, 21 Jun 2014 17:29:07 -0700:
I have two versions of my repository that I've saved from a while ago,
the last time I ran into this syncing issue. I've linked them both
here, hoping that someone can analyze them and figure out what the
issue is.
Indeed it
Thus said Michai Ramakers on Sun, 22 Jun 2014 10:44:05 +0200:
It looks like at least this random selection are all files that were
part of checkin a9b1344817, perhaps all of them are.
Thanks both for putting in time pinpointing this. This is probably no
news: diffing the complete
Thus said B Harder on Wed, 18 Jun 2014 10:52:22 -0700:
If everything is (ultimately) spawned from the initial empty
checkin, how can I be getting WARNING - no common ancestor: path
when merging one branch into another ?
How did you get to this error? In my case, I am able to
Thus said Richard Hipp on Wed, 18 Jun 2014 13:55:32 -0400:
There is the fossil test-ancestor-path HASH1 HASH2 command that you
can use to find common ancestors between two arbitrary check-ins.
Perhaps you can use that to figure out where the problem sits.
Nifty command. Here's the
Thus said to...@acm.org on Mon, 16 Jun 2014 00:14:20 +0300:
OK, my problem is not so much with the committing act per se (of
non-working code,) -- besides, you do have to have a mechanism of
adding your changes, even WIP ones, in the repo -- it's with ending up
with a history /
Thus said Richard Hipp on Fri, 13 Jun 2014 23:23:10 -0400:
This appears to be working now on trunk. Get the latest code. Rerun
./configure and recompile (on a Linux system with FuseFS support -
Ubuntu 13.10 works for me after apt-get install fuse). Then:
Nice work! It almost works on
Thus said Richard Hipp on Sat, 14 Jun 2014 13:14:10 -0400:
That is correct behavior. You cannot list the /checkins/ folder.
As I discovered after I read the ``fossil help fuse'' document.
I'm probably not setting an mtime on the checkins folder either.
The both the mount point and the
Thus said to...@acm.org on Sat, 14 Jun 2014 23:02:05 +0300:
1. If the only way is to use a special branch to do what I need, can
at least a single branch be reused multiple times?
Yes, you can do that with ease. There are a few branches like that in
the Fossil repository, but the most
Thus said Ron Aaron on Thu, 12 Jun 2014 17:40:02 +0300:
Twice this week, I encountered a situation where I did a commit from
one machine, and an update from the second -- and the second did not
get the latest updates.
What sync method was used on the first machine? On the second
Thus said Matt Welland on Wed, 16 Apr 2014 09:01:28 -0700:
Could fossil silently retry a couple times instead of giving up so
easily?
Not silent, but it can retry:
http://www.fossil-scm.org/index.html/info/76bc297e96211b50d7b7e518ba45663c80889f1f
This still won't avoid the occasional
Thus said Ron Aaron on Fri, 13 Jun 2014 07:43:25 +0300:
So I could have the situation where C1 pushes and is also pulling
(though locks should prevent any problems), and later on C2 pulls. I
don't have the super-long-time push, but it does seem to occur more
often when the push
Thus said Eric Rubin-Smith on Thu, 12 Jun 2014 14:46:09 -0400:
I have no idea how the sync code works, but at the time I suspected
that there is some sort of optimization involving timestamps, and a
slow sync can cause that code to get confused and miss some artifacts.
May or may not
Thus said Stephan Beal on Sat, 07 Jun 2014 11:27:24 +0200:
An alternative solution would be to tag them, of course. Ah, and the
commit command seems to have added a --tag feature, which would make
that trivial to do, but also requires re-training years of muscle
memory :/.
On the
Thus said Stephan Beal on Fri, 06 Jun 2014 18:29:26 +0200:
[stephan@host:~/cvs/fossil/fossil/src]$ grep 'TH command:' *.c
What about these?
$ grep 'TH1 command' th_main.c
** TH1 command: combobox NAME TEXT-LIST NUMLINES
** TH1 command: linecount STRING MAX MIN
** TH1 command:
Thus said Stephan Beal on Sat, 07 Jun 2014 00:21:56 +0200:
Ah, mixed conventions (TH vs TH1). Probably a historical oversight. i
grepped against 'TH ...' because the first example i came across used
that.
Yes, I actually recently discovered the mixed conventions while testing
the ticket
Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500:
I should add that it's not always possible or desirable to test all
commits in a bundle that will be pushed together. A goal of breaking
up large commits into smaller ones is to make it easier to understand
and backport them,
Thus said Warren Young on Thu, 05 Jun 2014 04:06:09 -0600:
I realize implementing all this will take a fair bit of work. When I
describe it as simple, I mean that I don't see that it changes a lot
about how Fossil works internally.
I wonder if it could start out as an external tool
Thus said Richard Hipp on Thu, 05 Jun 2014 09:14:17 -0400:
Suppose you had the ability to create a sub-repository - a kind of
clone of a full fossil repo but that only contains a small subset of
the check-ins (and/or wiki and tickets, etc.) A sub-repository would
not even be
Thus said Warren Young on Thu, 05 Jun 2014 09:25:39 -0600:
A contribution from an untrusted outsider needs to be checked
carefully before it is committed to the master repo.
Certainly.
fossil open subrepo.fossil
# inspect
fossil ui subrepo.fossil
# inspect
I'm not sure how many
Thus said Richard Hipp on Wed, 04 Jun 2014 07:47:43 -0400:
The merge logic in Fossil recognizes when the same exact change is
merged more than once and avoids conflicts in that case. The Q-cards
are not necessary for this.
What am I doing wrong then? In this case, I did a
Thus said Richard Hipp on Wed, 04 Jun 2014 14:34:31 -0400:
It clearly would not work for me.
As as an amateur user of Git, Git wasn't working for me---perhaps this
is simply due to misunderstanding ``core'' features of Git. At any rate,
thanks to Git I discovered Fossil and have been pleased
Thus said Martin Gagnon on Fri, 30 May 2014 05:55:58 -0400:
Same for me, I always use autosync=1 together with the dont-push=1
setting for that. Look like an option got added by someone that didn't
know about the other.
The actually do serve different purposes. dont-push=1 prevents
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
Hello,
While experimenting with --cherrypick I stumbled upon this situation:
$ fossil merge trunk
cannot find a common ancestor between the current checkout and trunk
$ f stat | grep checkout
checkout: 738e72e3d9cfe5568c94940c09ada1b78341ac68 2014-06-04 03:48:59 UTC
$ fossil artifact
Thus said Andy Bradford on Tue, 03 Jun 2014 21:59:21 -0600:
Does the Q-card here not imply any relation with c14a4a93d5a3 which will
be picked up in trunk?
It seems I did not understand this very well:
A Q-card is similar to a P-card in that it defines a predecessor
to the current
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 =?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 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 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 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 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 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 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
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
601 - 700 of 969 matches
Mail list logo
