I know how I can get the latest version; but I am quite concerned
that if I do update my system, my users will be unable to sync
unless they also go through that process.
I don't think it should be the case that I cannot sync to a repo
after an upgrade. W
On 04/11/2017 09:08 PM, Ron Aaron wrote:
My current fossil is "This is fossil version 1.37 [df1205bb3a]
2016-11-07 11:26:26 UTC", not such an old version.
Download binaries or source from here:
https://www.fossil-scm.org/index.html/uv/download.html
This will get you caught up with the sha3 ch
My current fossil is "This is fossil version 1.37 [df1205bb3a]
2016-11-07 11:26:26 UTC", not such an old version.
When I try to update to the latest fossil trunk, I get:
Autosync: https://fossil-scm.org/
Round-trips: 1 Artifacts sent: 0 received: 0
unknown command: [igot]
Rou
Hello Fossil Users, fyi ...
24th Annual Tcl/Tk Conference (Tcl'2017)
http://www.tcl.tk/community/tcl2017/
October 16 - 20, 2017
Crowne Plaza Houston River Oaks
2712 Southwest Freeway, 77098
Houston, Texas, USA
Important Dates:
Abstracts and proposals due August 21, 2017
Notification to autho
On 4/11/2017 3:24 PM, Thomas wrote:
This is actually one of the sources I based my exclusion list on.
I added other files too. I replaced all # characters at the beginning
of each line with semicolons, extracted the files like [Tt]umbs.db to
Thumbs.db and thumbs.db, saved it, and let my batch f
On 4/11/2017 3:24 PM, Thomas wrote:
On 2017-04-11 23:09, Ross Berteig wrote:
On 4/10/2017 11:48 AM, Thomas wrote:
Actually, I got a batch file that reads the file filter settings from
another file and creates the binary-glob and the ignore-glob files on
the fly before an addremove and a comm
[Default] On Tue, 11 Apr 2017 21:25:31 +0100, Thomas
wrote:
>On 2017-04-11 21:04, Ross Berteig wrote:
>> The fossil addremove command is a convenience command that scans the
>> tree, obeying some of the glob settings, and applies fossil add and
>> fossil forget command as needed to make the list
On Tue, Apr 11, 2017 at 4:11 PM, Thomas wrote:
> On 2017-04-11 22:51, Scott Robison wrote:
>>
>> On Tue, Apr 11, 2017 at 3:39 PM, Scott Robison
>> wrote:
>>>
>>> On Tue, Apr 11, 2017 at 3:21 PM, Thomas wrote:
On 2017-04-11 22:11, Thomas wrote:
add
--ignoreIgno
On 2017-04-11 23:09, Ross Berteig wrote:
On 4/10/2017 11:48 AM, Thomas wrote:
Actually, I got a batch file that reads the file filter settings from
another file and creates the binary-glob and the ignore-glob files on
the fly before an addremove and a commit (crlf-glob is not created and
only c
On 2017-04-11 22:51, Scott Robison wrote:
On Tue, Apr 11, 2017 at 3:39 PM, Scott Robison wrote:
On Tue, Apr 11, 2017 at 3:21 PM, Thomas wrote:
On 2017-04-11 22:11, Thomas wrote:
add
--ignoreIgnore unmanaged files matching
patterns from the comma separated l
On 4/10/2017 11:48 AM, Thomas wrote:
Actually, I got a batch file that reads the file filter settings from
another file and creates the binary-glob and the ignore-glob files on
the fly before an addremove and a commit (crlf-glob is not created and
only contains an asterisk now).
Why do this
On 2017-04-11 22:21, Thomas wrote:
On 2017-04-11 22:11, Thomas wrote:
On 2017-04-11 22:01, Scott Robison wrote:
I was thinking about that earlier (well, a warning, not an error,
which presumes you can't continue). Then the questions I put above
came into my mind so I didn't bring it up. What wo
I've been using fossil for several years now, so when I set up a new fossil
my first operation is to copy over an existing .fossil-settings and commit,
so I haven't been exposed to this problem for a while. I certainly
remember when I first used it that it did some unexpected things. Perhaps
if th
On Tue, Apr 11, 2017 at 3:39 PM, Scott Robison wrote:
> On Tue, Apr 11, 2017 at 3:21 PM, Thomas wrote:
>> On 2017-04-11 22:11, Thomas wrote:
>>
>> add
>>--ignoreIgnore unmanaged files matching
>> patterns from the comma separated list of
>>
On Tue, Apr 11, 2017 at 3:21 PM, Thomas wrote:
> On 2017-04-11 22:11, Thomas wrote:
>>
>> On 2017-04-11 22:01, Scott Robison wrote:
>>>
>>> I was thinking about that earlier (well, a warning, not an error,
>>> which presumes you can't continue). Then the questions I put above
>>> came into my mind
On Tue, Apr 11, 2017 at 3:11 PM, Thomas wrote:
> On 2017-04-11 22:01, Scott Robison wrote:
>>
>> On Tue, Apr 11, 2017 at 2:31 PM, David Mason wrote:
>>>
>>> I think --ignore should give an error if the --ignore matches a file
>>> already
>>> in the repository. The current behaviour is clearly so
On Tue, Apr 11, 2017 at 3:04 PM, Thomas wrote:
> On 2017-04-11 19:34, Scott Robison wrote:
>>
>> No, I try to explain why what you see isn't a design flaw, and
>> apparently fail. But I'll keep trying!
>
>
> Since I've never heard of any software that would not ignore files it is
> told to ignore
On 2017-04-11 22:11, Thomas wrote:
On 2017-04-11 22:01, Scott Robison wrote:
I was thinking about that earlier (well, a warning, not an error,
which presumes you can't continue). Then the questions I put above
came into my mind so I didn't bring it up. What would you suggest
calling the command?
On 2017-04-11 22:01, Scott Robison wrote:
On Tue, Apr 11, 2017 at 2:31 PM, David Mason wrote:
I think --ignore should give an error if the --ignore matches a file already
in the repository. The current behaviour is clearly somewhat ambiguous.
...
I was thinking about that earlier (well, a wa
On 2017-04-11 19:34, Scott Robison wrote:
No, I try to explain why what you see isn't a design flaw, and
apparently fail. But I'll keep trying!
Since I've never heard of any software that would not ignore files it is
told to ignore you're going to have a hard time to convince me ;-)
Source
On Tue, Apr 11, 2017 at 2:31 PM, David Mason wrote:
>
> On 11 April 2017 at 14:34, Scott Robison wrote:
>>
>> No, it is an explicit command clearly stating the user's desire for
>> exclusion of these files *that are not already under source control*.
>> The fact that the user does not remember or
On 11 April 2017 at 14:34, Scott Robison wrote:
> No, it is an explicit command clearly stating the user's desire for
> exclusion of these files *that are not already under source control*.
> The fact that the user does not remember or did not realize they
> issues conflicting commands does not m
On 2017-04-11 21:04, Ross Berteig wrote:
The fossil addremove command is a convenience command that scans the
tree, obeying some of the glob settings, and applies fossil add and
fossil forget command as needed to make the list of files now in the
repository consistent with the settings and the di
On 4/11/2017 9:36 AM, Thomas wrote:
I would like to emphasise that --ignore (or
.fossil-settings\ignore-glob) is an _explicit_ command, clearly
stating the user's desire for exlusion of these files, following the
documentation.
Silently ignoring this wish can't be the correct process.
But t
On Tue, Apr 11, 2017 at 10:36 AM, Thomas wrote:
> On 2017-04-11 05:22, Scott Robison wrote:
>>
>> Perhaps it should be documented, but I don't think it is a bug. It is
>> the software doing the job it was originally told to do (track versions
>> of a file) instead of doing the job it was subsequen
On 2017-04-11 10:02, Mark Janssen wrote:
That's not a security hole at all. Once a file was added, ignoring it
will not remove past version from the repository. History in fossil is
immutable. If you inadvertently added a file which shouldn't be there
you should shun it instead.
The way I under
LOL ;-)
Forwarded Message
Subject:Re: [fossil-users] Issue with ignore-glob
Date: Tue, 11 Apr 2017 16:47:01 +
From: Eboni
Reply-To: Eboni
To: tho...@dateiliste.com
Hey Thomas ,
Yes I'm Real.To prove I'm real first off.. today is (day) And your L
On 2017-04-11 05:22, Scott Robison wrote:
Perhaps it should be documented, but I don't think it is a bug. It is
the software doing the job it was originally told to do (track versions
of a file) instead of doing the job it was subsequently told to do
(ignore untracked files with a given glob).
F
On 2017-04-11 10:02, Mark Janssen wrote:
That's not a security hole at all. Once a file was added, ignoring it
will not remove past version from the repository. History in fossil is
immutable. If you inadvertently added a file which shouldn't be there
you should shun it instead.
It is very well
On Tue, Apr 11, 2017 at 11:44 AM, ng0 wrote:
> I'm updating our Fossil package to the 2.x series, and I saw a message
> about json support being disabled.
> Is this something users of fossil expect to be enabled when they use it?
>
json support has never been enabled by default.
--
- steph
Hi,
I'm updating our Fossil package to the 2.x series, and I saw a message
about json support being disabled.
Is this something users of fossil expect to be enabled when they use it?
Our policy is to follow upstream as closely as possible, I'm not a user
of fossil myself at the moment.
--
PGP and
That's not a security hole at all. Once a file was added, ignoring it
will not remove past version from the repository. History in fossil is
immutable. If you inadvertently added a file which shouldn't be there
you should shun it instead.
On Tue, Apr 11, 2017 at 1:27 AM, Thomas wrote:
> On 2017-0
32 matches
Mail list logo
