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.
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
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]
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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 ;-)
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*.
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
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
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
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
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
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
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).
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
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
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
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
31 matches
Mail list logo