[fossil-users] Dilbert Git

[Scott Robison]

In reading today's Dilbert, I imagined how it applies to git:
http://dilbert.com/strip/2018-05-02?utm_source=dilbert.com/newsletter_medium=email_campaign=brand-loyalty_content=strip-image

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Setting up an internet Fossil server

[Scott Robison]

I've done similar work for my own lighttpd based personal server. If you'd
like I can share my config, maybe it would be helpful.

On Feb 26, 2018 1:36 PM, "Roy Keene"  wrote:

> Scott,
>
> Fossil can be run in any URL suffix on an existing domain.  This
> is how, for example ChiselApp.com works -- each user*repo is a different
> URL and they run their own repositories, while the rest of the site runs
> PHP.
>
> Thanks,
> Roy Keene
>
> On Mon, 26 Feb 2018, Scott Doctor wrote:
>
>
>> Going to give this a try. (also busy with other pay-the-bills work so I
>> tend to do this one in my spare (ha) time).
>>
>> The issue I am trying to figure out is that it seems it is an all or
>> nothing setup. Either the website is using fossil as the website or not at
>> all. Most of the website is HTML5 and php pages that have nothing to do
>> with the fossil archive. It is the functionality of the random number
>> generator, api, and website UI I designed that I am packaging up as an open
>> source project. Hence the use of fossil.
>>
>> What I want is for fossil to activate when I access a specific directory
>> to use fossil.
>>
>> https://nousrandom.net/code/
>>
>> But it appears I am going to have to make a sub-domain to do this.
>>
>> I put the fossil program in that folder, and through the command line
>> interface (via putty) created a new archive in that folder. However, when I
>> issue the command
>>
>> fossil server --scgi
>>
>> the program runs in the foreground and the command line control is
>> unusable until I ctrl-c.
>>
>> So I guess I need to create a sub-domain to use fossil.
>>
>> Still have not yet got it to work even as a stand-alone.
>>
>> To be continued...
>>
>>
>> -
>> Scott Doctor
>> sc...@scottdoctor.com
>> -
>>
>> On 2/26/2018 05:17, Warren Young wrote:
>>
>>> On Feb 24, 2018, at 11:57 AM, Scott Doctor 
>>> wrote:
>>>

 Is there a step-by-step how to get fossil to work from an internet page?

>>> I?ve posted this here several times now:
>>>
>>> https://www.mail-archive.com/fossil-users@lists.fossil-scm.o
>>> rg/msg22907.html
>>>
>>> Since you?ve already got Let?s Encrypt working with nginx, you can skip
>>> all of that.  The HOWTO was written before Let?s Encrypt had built-in
>>> support for nginx.
>>>
>>> ___
>>> fossil-users mailing list
>>> fossil-users@lists.fossil-scm.org
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti

[Scott Robison]

Forged should be a skull and crossbones. I would think yellow and red
unlocked locks and green locked locks, but definitely with hover text for
those of us with faulty color perception.

On Dec 21, 2017 3:16 PM, "Richard Hipp"  wrote:

> On 12/21/17, jungle Boogie  wrote:
> >
> > How are the signatures verified?
>
> Signatures are not verified, at the moment.
>
> Probably each repository would have a set of trusted public keys.
> Then as each check-in is received via push (or during a rebuild) those
> with signatures have the signatures verified using the set of trusted
> keys.  Those for which the keys are unknown get marked as signed but
> unverified.
>
> The signatures are currently generated by running gpg in a separate
> process.  I suppose the verification step could do something similar.
>
> Hey - I suppose there is a fourth state:  (4) Forgery: The signature
> does not match.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Scott Robison]

I'd bet that you can commit as anyone and push it if you have that access.
You probably wouldn't keep that access for long, though.

On Dec 14, 2017 12:13 PM, "Warren Young"  wrote:

> On Dec 14, 2017, at 10:19 AM, jungle Boogie 
> wrote:
> >
> > So Warren edited a file at the same exact time as tangent?
>
> Fossil arguably has a bug here, where if you check a change in as local
> user name “tangent”, as I do here, then *later* do a “fossil sync” to a URL
> with a user name, some bit of the local on-disk state remembers that you
> originally cloned the repo as tangent and makes your changes under that
> name.  Then when you go to push to the remote repo, it uses your remote
> user name and password credentials, but the changes are tagged with your
> local user name.
>
> I think Fossil ought to catch this kind of thing and either silently
> rewrite the user name or force some local fix-up it can’t be done
> automatically for some reason.
>
> This kind of thing happens when a previous outsider to a project is later
> granted privileges, but under a different name.
>
> I assume Fossil is the way it currently is because:
>
> a) many people use the same user name everywhere
> b) it’s a rare occurrence; and
> c) it’s easy to fix when it happens
>
> But even knowing all of this, it’s happened to me twice with the
> fossil-scm.org repository, once from two different machines.  The first
> was a pure surprise to me on my first checkin to fossil-scm.org, and the
> second happened to me yesterday because I missed one client machine when I
> went around and closed, re-cloned and re-opened the fossil-scm.org
> repository to make each one forget about user tangent.
>
> I classify this as a bug because it could be used for an impersonation
> attack.  I expect that it would not allow me to check changes in as drh
> simply by creating a local drh user, since that’s a known user and I cannot
> produce drh’s password, but it certainly will let me check changes in as
> billgates.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Lots of web interface changes

[Scott Robison]

I read that as no, he isn't having the same problem.

On Dec 6, 2017 2:59 PM, "Richard Hipp"  wrote:

> On 12/6/17, Stephan Beal  wrote:
> > On Wed, Dec 6, 2017 at 8:33 PM, Richard Hipp  wrote:
> >
> >> know.)  Are you still having the same problem with the latest
> >> code, even after hitting multiple "Reloads"?
> >>
> >
> > Just tested: no :)
>
> I just brought up chrome here on my desktop and on a Win7 laptop and
> they both seems to be working fine.  Can you give me more information
> on how to repro the problem?
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG Bloat?

[Scott Robison]

On phone, apologies in advance for top posting...

The value I see from multi vcs support isn't providing easy setup of
hosting one repo on multiple formats (though that would be awesome). I like
the idea of using fossil at work where I'm forced to use git (or Perforce,
though that hasn't been mentioned). I would love a sane command line with
integrated web UI to access multiple repository formats.

I support the idea and would love to help with it. I think a VFS-ish API to
"simplify" integration of multiple formats would be great. If you didn't
want to support multiple repository formats or use fossil with other
formats, I can imagine it being simple to compile the other ones out. But
if I never had to use another vcs directly ever again, I'd be happy.

On Nov 21, 2017 5:22 PM, "Offray Vladimir Luna Cárdenas" 
wrote:

> I agreed with Zoltán as also just a mortal Fossil user. Of course time
> will tell if the path of Fossil-NG serves well current and future users
> and others and of course everybody does what they want with their time
> and effort. I don't see the point of raising this in the users list if
> any voice we raise as users is answered as dumb or rudely by more
> experienced users or devs.
>
> Cheers,
>
> Offray
>
>
> On 21/11/17 18:52, Warren Young wrote:
> > On Nov 21, 2017, at 4:44 PM, Zoltán Kócsi  wrote:
> >> Adding unnecessary complexity to its innermost workings would open the
> >> door to a maintenance hell, I think.
> > If it were someone else proposing this feature as something for drh to
> do, then I might well agree with you, but since it is drh proposing work
> that drh will almost certainly end up doing, that changes things
> drastically.
> >
> > Not only is it his time to do with as he pleases, he also has a far
> better chance of pulling this off, any personal brilliance aside, purely
> because it’s apparently his own itch.
> >
> > Thus I cheerlead.
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] manifest setting "l" flag

[Scott Robison]

On Sep 29, 2017 7:43 AM, "Andy Goth" <andrew.m.g...@gmail.com> wrote:

On 09/28/17 21:34, Scott Robison wrote:

> There is a winsymlink branch I created some time ago. Hasn't been kept
> up to date (I didn't need it, just thought it might be useful for
> feature parity) but I could take a look at it if you were interested.
> Or you could.
>

I had a peek.  I know Windows NT derivatives allow symlinks to directories
but was not aware any version of Windows allowed symlinks to files.  What
is the status of that?


Vista and later allow symlinks to both, though it treats them as separate
types of symlinks. That is part of the awkwardness of trying to paper over
the differences between posix & Windows.

Having symlinks in Windows may seem cool at first, but it would actually be
counterproductive without a good way to edit them.  If Fossil is the only
program on hand that can create, change, or unlink them, it might as well
not even try.


The system does include utilities to create and delete them.

Plus, the project I'm doing has to work all the way back to Windows 2000
and (maybe, possibly, unconfirmed) Windows 98.


On that my branch cannot help.

  While it's not the end of the world if there are some platforms which
can't be used as a build or development platform, right now I have it so
that any supported system is fully capable of developing for all supported
systems: Linux for Windows, Windows for Linux, etc.  Therefore I do not
want to rely on features that aren't bog standard throughout every version
of Windows, 95 onward because long filenames.


Good luck, though based on my admittedly limited understanding, this seems
like such a departure from what any supported system does that it feels
like a separate utility or make step or something is called for.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] manifest setting "l" flag

[Scott Robison]

There is a winsymlink branch I created some time ago. Hasn't been kept up
to date (I didn't need it, just thought it might be useful for feature
parity) but I could take a look at it if you were interested. Or you could.

On Sep 28, 2017 7:08 PM, "Andy Goth"  wrote:

> http://fossil-scm.org/index.html/info/8d6bdd1e00cf2cf8
>
> I added support for a new "l" flag to the "manifest" setting.  With this
> flag present, a new file "manifest.symlinks" is automatically created and
> maintained.  This file lists all symlinks (not their targets).
>
> I need this feature for a project that makes extensive use of symlinks and
> has to work on Windows even though the OS doesn't really have symlinks (at
> least not symlinks to files).  On this project, I currently have a symlink
> list file which I maintain by running a script on Linux and checking in the
> result.
>
> When I run on Windows, everything in the project that actually needs to
> use symlinks looks at the symlinks file to see if it should read the file
> to get its target before proceeding.
>
> This works pretty well for me but is kind of awkward.  I'd rather have the
> symlinks file be kept up to date, no fooling, without being a separately
> checked-in file.
>
> However, it's not 100% what I need.  When working on Windows, I'd like to
> also be able to edit manifest.symlinks to change which files are and are
> not considered to be symlinks.
>
> I believe the current Fossil logic for handling symlinks on Windows is to
> create them as ordinary files containing their targets (no trailing
> newline), then leave them as symlinks in the manifest until they are
> changed.  I'm thinking that when the "l" flag is set, the logic would
> instead be to reread the manifest.symlinks file when doing a commit and use
> it to decide what to mark as symlinks in the manifest.  Said logic would
> only apply in Windows.
>
> --
> Andy Goth | 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Problem with: fossil revert -r xxx

[Scott Robison]

I'm on the road and may not be thinking clearly, but if you're trying
to revert your entire tree to the state 6 or 7 commits ago, might it
be easier to update to the commit you want, rename the first commit in
the now unwanted branch, and continue on from the new root?
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] A tutorial about "branches", "trunks", "leafs", etc.?

[Scott Robison]

On Apr 29, 2017 8:30 PM, "The Tick"  wrote:

OK, I think I've figured it out!

You're supposed to do a fossil >open< with a version name being "trunk"
(default) or "branch name". When finished, do a fossil close.

It appears that I can even do this in separate directories at the same time
-- one instance open with the default "trunk" and another instance with
"branch name". A commit in one of the directories will apply those changes
against the branch that was opened in that directory.

Wow! I kept thinking that one would somehow specify the branch against
which the changes were to apply when one did a commit.

Am I right or at least not too far off?


The commit is applied to the last branch. If you want to switch branches,
you can use "fossil update branch-name".
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with crlf-glob *

[Scott Robison]

On Wed, Apr 12, 2017 at 4:41 PM, Thomas <tho...@dateiliste.com> wrote:
> On 2017-04-12 23:24, Scott Robison wrote:
>>
>> When I am using the download from fossil-scm.org, I am able to use
>> single quotes to 'escape' the asterisk. Double quotes do not work.
>
>
> On Windows?
> How'd you do that?

Using a copy of fossil.exe 2.2 I just downloaded from fossil's
download page a minute ago, from a command prompt on Windows 10 Pro,
as follows:

D:\temp\work>fossil settings ignore-glob
ignore-glob

D:\temp\work>fossil extras
c.a
x/a.a
x/b.b
x/c.a
z.a

D:\temp\work>fossil settings ignore-glob '*'

D:\temp\work>fossil settings ignore-glob
ignore-glob  (local)  '*'

D:\temp\work>fossil extras

D:\temp\work>fossil unset ignore-glob

D:\temp\work>fossil extras
c.a
x/a.a
x/b.b
x/c.a
z.a

D:\temp\work>fossil settings ignore-glob '*.a'

D:\temp\work>fossil extras
x/b.b

D:\temp\work>fossil settings ignore-glob *.a
Usage: fossil settings ?PROPERTY? ?VALUE? ?-global?

Unquoted in the last example, *.a doesn't work. Single quoted it does.
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with crlf-glob *

[Scott Robison]

On Wed, Apr 12, 2017 at 2:10 PM, Thomas <tho...@dateiliste.com> wrote:
> On 2017-04-12 18:01, Scott Robison wrote:
>>
>> On Apr 12, 2017 10:31 AM, "Thomas" <tho...@dateiliste.com
>> <mailto:tho...@dateiliste.com>> wrote:
>>
>> On 2017-04-09 02:19, Richie Adler wrote:
>>
>> Thomas decía, en el mensaje "[fossil-users] Issue with crlf-glob
>> *" del
>> 8/4/2017 17:46:14:
>>
>> Does anyone know how to unveil the secret of getting the
>> mentioned
>> asterisk into the crlf-glob setting without consulting the
>> web interface?
>>
>>
>> For me, it works if I enter the asterisk as '*'.
>>
>> I'm on Windows 7 Ultimate Build 7601 SP 1.
>>
>> This is fossil version 2.2 [9612d43f93] 2017-03-18 14:10:13 UTC
>> Compiled on Mar 18 2017 13:48:53 using mingw32 (64-bit)
>>
>>
>> It's obviously not the version. It still doesn't work here.
>> This is fossil version 2.2 [a9d1d46f65] 2017-04-12 11:39:23 UTC
>> Compiled just now ...
>>
>>
>> Probably the difference between the Microsoft and MINGW run time
>> libraries.
>
>
> Most likely, yes. That's pretty much the only option left now. ;)
> Unless, of course, the provided exe at
> https://www.fossil-scm.org/fossil/uv/download.html has not been built with
> MSVC. If it's been built with MinGW we're back at square 1.
>
> In my case, I got two working solutions now:
> - Use "*," instead of just "*".
> - Write the asterisk to .fossil-settings\crlf-glob directly (which I like
> more).

I must have misread ... I thought you said you'd built with Visual C++
2015. Probably someone else.

When I am using the download from fossil-scm.org, I am able to use
single quotes to 'escape' the asterisk. Double quotes do not work.
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with crlf-glob *

[Scott Robison]

On Apr 12, 2017 10:31 AM, "Thomas"  wrote:

On 2017-04-09 02:19, Richie Adler wrote:

> Thomas decía, en el mensaje "[fossil-users] Issue with crlf-glob *" del
> 8/4/2017 17:46:14:
>
> Does anyone know how to unveil the secret of getting the mentioned
>> asterisk into the crlf-glob setting without consulting the web interface?
>>
>
> For me, it works if I enter the asterisk as '*'.
>
> I'm on Windows 7 Ultimate Build 7601 SP 1.
>
> This is fossil version 2.2 [9612d43f93] 2017-03-18 14:10:13 UTC
> Compiled on Mar 18 2017 13:48:53 using mingw32 (64-bit)
>

It's obviously not the version. It still doesn't work here.
This is fossil version 2.2 [a9d1d46f65] 2017-04-12 11:39:23 UTC
Compiled just now ...


Probably the difference between the Microsoft and MINGW run time libraries.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Tue, Apr 11, 2017 at 4:11 PM, Thomas <tho...@dateiliste.com> wrote:
> On 2017-04-11 22:51, Scott Robison wrote:
>>
>> On Tue, Apr 11, 2017 at 3:39 PM, Scott Robison <sc...@casaderobison.com>
>> wrote:
>>>
>>> On Tue, Apr 11, 2017 at 3:21 PM, Thomas <tho...@dateiliste.com> wrote:
>>>>
>>>> On 2017-04-11 22:11, Thomas wrote:
>>>>
>>>> add
>>>>--ignoreIgnore unmanaged files matching
>>>> patterns from the comma separated list of
>>>> glob patterns.
>>>>--exclude   Exclude files matching patterns from
>>>> the comma separated list of glob patterns.
>>>>
>>>> The same for addremove, I guess.
>>>
>>>
>>> I've updated the documentation for --ignore for add and addremove.
>>> Adding exclude is more than I have time for at this moment. Baby
>>> steps.
>>
>>
>> I still think there is a fundamental misunderstanding about addremove.
>
>
> I think not a misunderstanding but I made a minor error. There's nothing
> wrong with the add command as it currently is. This --exclude would only
> apply to addremove because the add command has it already (= rm or delete).

{snipped}

Okay, so you *do* want (or at least expected) the use of --ignore (in
the context of addremove) to "rm" files already being managed. Which
is not an unreasonable desire, certainly could make some work flows
easier. The addremove command was structured around the idea of "this
unmanaged file that exists in the working directory should be added at
the next commit, and this managed file that no longer exists in the
woking directory should be removed at the next commit".

In any case, the "unmanaged files" text is a good addition to both, I
think, since add can be used to add the contents of a directory.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Tue, Apr 11, 2017 at 3:39 PM, Scott Robison <sc...@casaderobison.com> wrote:
> On Tue, Apr 11, 2017 at 3:21 PM, Thomas <tho...@dateiliste.com> wrote:
>> On 2017-04-11 22:11, Thomas wrote:
>>
>> add
>>--ignoreIgnore unmanaged files matching
>> patterns from the comma separated list of
>> glob patterns.
>>--exclude   Exclude files matching patterns from
>> the comma separated list of glob patterns.
>>
>> The same for addremove, I guess.
>
> I've updated the documentation for --ignore for add and addremove.
> Adding exclude is more than I have time for at this moment. Baby
> steps.

I still think there is a fundamental misunderstanding about addremove.

You create a new repo. You run fossil addremove and get everything in
there, including things you don't want because you've never setup
ignore globs. You commit.

Now you know you need ignore, so you type fossil addremove --ignore
'*.whatever'. Files matching *.whatever that are already in the repo
will not be removed from the repo. Files matching *.whatever that are
not in the repo will not be added to the repo. fossil addremove does
not commit files, it just prepares to add or remove them in the next
commit.

Has your point been that running "addremove --ignore '*.whatever'"
treat files matching those patterns as missing so they will be removed
at the next commit? I don't think so because you said you didn't
expect it to remove the files. But you are surprised that --ignore
isn't ignoring files in addremove, and according to each and every
test I've run, it does ignore those unmanaged files so they are not
added.

Maybe you could try a new repository from scratch and try it the way I
described in my earlier posts. Or maybe you could give me the exact
command line you are running, and the fossil version output, and even
the OS / shell you are using so that I can see if there is something
else surprising about this.
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Tue, Apr 11, 2017 at 3:21 PM, Thomas <tho...@dateiliste.com> 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 would you suggest
>>> calling the command?
>>
>>
>> Change the text for --ignore and .fossil-settings/ignore-glob to:
>> unmanaged matching files to ignore
>>
>> Add another switch --exclude and .fossil-settings/exclude-glob and
>> explain that this applies to all, managed and unmanaged files
>> unconditionally.
>>
>> But right after that you'd have to start drinking beer as my offer still
>> stands ;-)
>
>
>
> add
>--ignoreIgnore unmanaged files matching
> patterns from the comma separated list of
> glob patterns.
>--exclude   Exclude files matching patterns from
> the comma separated list of glob patterns.
>
> The same for addremove, I guess.

I've updated the documentation for --ignore for add and addremove.
Adding exclude is more than I have time for at this moment. Baby
steps.
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Tue, Apr 11, 2017 at 3:11 PM, Thomas <tho...@dateiliste.com> wrote:
> On 2017-04-11 22:01, Scott Robison wrote:
>>
>> On Tue, Apr 11, 2017 at 2:31 PM, David Mason <dma...@ryerson.ca> 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.
>>
> Change the text for --ignore and .fossil-settings/ignore-glob to:
> unmanaged matching files to ignore
>
> Add another switch --exclude and .fossil-settings/exclude-glob and explain
> that this applies to all, managed and unmanaged files unconditionally.
>
> But right after that you'd have to start drinking beer as my offer still
> stands ;-)

I'll be happy to enjoy a root beer with you. That's as far as I'll go. :)
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Tue, Apr 11, 2017 at 3:04 PM, Thomas <tho...@dateiliste.com> 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 you're going to have a hard time to convince me ;-)

I'll concede that the thoughts of the fossil devs heavily influence
how options work and what they think they should do. I would be
surprised if a file I told the system to track was not because of some
other set of files I wanted to ignore.

>>> Source code management != backup
>>
>>
>> Never said it was. Keeping an obj file in a repo because there is no
>> corresponding source from which to build it is valuable so that other
>> people can get access to all the build artifacts required.
>
>
> Keeping hundreds of megabytes of SQLite Visual Studio Intellisense databases
> is not something required to build the software. It is also not something
> desirable to delete on the originating machine just to satisfy the odd
> behaviour of the SCM. To be fair, Fossil does a very good job in only
> storing the compressed differences. Although the files are quite big, the
> repository only grew by about 10 or 12 MiB with each commit.

I never suggested anyone would want to track megabytes of such files.

> I believe that Fossil users are software developers and know what happens to
> object files they exclude. I believe they're smart enough to either rename
> object files they need in the repository if they set up exclusion filters,
> or that they would set up appropriate filters. They'd find out as soon as
> they test it, and they can find out with "fossil ui". In my opinion this is
> a very weak excuse. ;)

Or maybe they're smart enough to use the software as designed. #zing
#sorry #lowblow

I kid, really. I understand most of your points. There is definitely
room for confusion.

>>> 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.
>>
>>
>> No, it is an explicit command clearly stating the user's desire for
>> exclusion of these files *that are not already under source control*.
>
>
> That's not what the documentation says ;-)

To be fair, the documentation doesn't really say either way. One would
need a standards body to write documentation that has no issues. And
even then there are still issues because someone comes along later and
disagrees with what a set of words should be defined to mean.

Unless of course you're talking about the documentation in the source
code fragment you quoted earlier, in which case it did say that it was
only building a list of unmanaged files.

>> The fact that the user does not remember or did not realize they
>> issues conflicting commands does not mean that fossil should suddenly
>> stop tracking the file, or so it seems to me.
>>
>> If a file was previously added to a repository (indicating a desire to
>> keep track of modifications to the file), that is more important than
>> ignoring the file.
>
>
> Isn't it a natural thing that the first step everyone does when trying out a
> revision management system is commit everything they got as they haven't set
> up any exclusions at that time?

Not for me. I run changes and extras commands almost every time I run
addremove just to be sure there aren't any surprises, and if I find
any, I will update glob patterns as needed.

> I can't imagine that this is really its intended function. If it really is,
> then this should be marked in triple-bold and red with green and pink
> stripes in the docs.

One of my earliest replies was a concession that documentation may
need to be updated.

>>> File add.c on line 672 says:
>>>   /* step 1:
>>>   ** Populate the temp table "sfile" with the names of all unmanaged
>>>   ** files currently in the check-out, except for files that match the
>>>   ** --ignore or ignore-glob patterns and dot-files.  Then add all of
>>>   ** the files in the sfile temp table to the set of managed files.
>>>   */
>>> According to this, it seems it's a design flaw.
>>
>> The key words are at the end of line 673 and the beginning of line
>> 674: "unmanaged files". By definition, a managed file (one that has
>> been previously added to the repository) is not an unmanaged file.
>> Thus it is working as described.
>
> That's from the source code of 

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Tue, Apr 11, 2017 at 2:31 PM, David Mason <dma...@ryerson.ca> wrote:
>
> On 11 April 2017 at 14:34, Scott Robison <sc...@casaderobison.com> 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 mean that fossil should suddenly
>> stop tracking the file, or so it seems to me.
>>
>> If a file was previously added to a repository (indicating a desire to
>> keep track of modifications to the file), that is more important than
>> ignoring the file.
>
>
> I think --ignore should give an error if the --ignore matches a file already
> in the repository.  The current behaviour is clearly somewhat ambiguous.

It would be relatively easy to warn if a modified file matches the
glob. Would you want it to search an entire checkout each and every
time for all files that are monitored to see if they match? Should it
always scan all files at every commit (even if they aren't in the
current checkout) to find conflicts?

I'm not trying to be flippant. I'm really not sure just how far to go
down the rabbit hole, especially for a bit of functionality that has
worked as expected for most people (presumably) for years (though
maybe it isn't working the way anyone expects except for the few
people who've weighed in defending it).

> Alternately (or additionally!) a command that would check and report if
> there is any file(s) that would match the --ignore or the ignore-glob flag
> would be helpful.

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?
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Tue, Apr 11, 2017 at 10:36 AM, Thomas <tho...@dateiliste.com> 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 subsequently told to do
>> (ignore untracked files with a given glob).
>>
>> For example, I have licensed libraries in the past that are shipped as
>> obj files. They need to be tracked, even though most obj files don't.
>> This model allows you to add certain obj files which will be tracked
>> while ignoring all others.
>
>
> You're a good salesman. ;-)
>
> Do you work for Microsoft by any chance? You're trying to sell a design flaw
> or bug as a feature. ;-)

No, I try to explain why what you see isn't a design flaw, and
apparently fail. But I'll keep trying!

> Source code management != backup

Never said it was. Keeping an obj file in a repo because there is no
corresponding source from which to build it is valuable so that other
people can get access to all the build artifacts required.

> 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.

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 mean that fossil should suddenly
stop tracking the file, or so it seems to me.

If a file was previously added to a repository (indicating a desire to
keep track of modifications to the file), that is more important than
ignoring the file.

> A switch that doesn't work is either a huge design flaw or a bug. A --ignore
> switch that doesn't ignore is a huge security bug (and a trap) too.

Ignoring does work as desired. It only applies to files that match the
pattern that are not already in source control.

> What would I need a --ignore switch for when I got to delete the files first
> manually anyway? That's completely contrary to its purpose, isn't it? The
> reason why I'm using --ignore is because I _don't want_ to delete these
> files.

Going back to my examples from yesterday: I had an ignore-glob of *.a.
I ran addremove and it ignored the a.a file, but not the b.b file. If
I ran add a.a, it warned me that it was in the ignore pattern, but
allowed me to add it anyway.

Today I went back to that example repository and created a file c.a
and ran addremove. It ignored c.a because I had not added it
previously.

If I delete the ignore-glob file and use the --ignore switch with
'*.a' it behaves identically.

> Every virus scanner, backup software, mirroring software, every other source
> code revision management, webserver, and god knows what else, follows its
> exclusion rules.

--ignore is not a "remove existing files from the repository rule"
switch. It is an "ignore unmanaged files that match a pattern" switch.

> Sorry, I can't see any logic behind this, apart from that this bug or design
> issue may have slipped in accidentally and now no one's willing to fix it,
> but trying to defend and advertise it as a feature... ;)

Just because you can't see it doesn't mean it isn't there. It is an
intentional design to allow the ignoring of unmanaged files.

> File add.c on line 672 says:
>   /* step 1:
>   ** Populate the temp table "sfile" with the names of all unmanaged
>   ** files currently in the check-out, except for files that match the
>   ** --ignore or ignore-glob patterns and dot-files.  Then add all of
>   ** the files in the sfile temp table to the set of managed files.
>   */
> According to this, it seems it's a design flaw.

The key words are at the end of line 673 and the beginning of line
674: "unmanaged files". By definition, a managed file (one that has
been previously added to the repository) is not an unmanaged file.
Thus it is working as described.

The only thing I can think at this point is that you believe that if
*any* file matching a glob pattern is in the repository, all files
matching that same glob pattern will be added to the repository
despite the glob pattern. This is not how my current version of fossil
(downloaded from the fossil-scm site a few days ago) behaves. Only
files already in the repository (managed files) with changes will be
committed.
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Apr 10, 2017 5:02 PM, "Thomas" <tho...@dateiliste.com> wrote:

On 2017-04-10 22:28, Scott Robison wrote:

> On Mon, Apr 10, 2017 at 2:57 PM, Thomas <tho...@dateiliste.com> wrote:
>
>> I reckon I owe you a beer! ;-)
>>
>
> Not at all. I don't drink, anyway. Well, not beer. :)
>

You're probably missing one of the best parts in life here ;-)



Anyway, your suggestion sounds very reasonable (ok, it doesn't sound
>> reasonable at all to be honest, but I think that's what happened).
>>
>
> I think if you add a file to a repo then add an ignore, it is safer to
> keep maintaining it rather than suddenly ignoring it. The two events
> are conflicting, so fail safe. Removing the file allows it to be
> ignored going forward.
>

I just tried it. Yepp, that was it. ;-)

The --ignore argument as well as the .fossil-settings\ignore-glob file
don't work for files or file masks that have been committed at some point
after the repository has been created. Your work-around worked. After
deleting some of these files, committing, changing, and committing again,
they were ignored/not checked in afterwards.

I'd say this is either a big design flaw or a bug.
It's not mentioned anywhere in the documentation and is anything but
logical and reasonable.


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).

For example, I have licensed libraries in the past that are shipped as obj
files. They need to be tracked, even though most obj files don't. This
model allows you to add certain obj files which will be tracked while
ignoring all others.


I reckon everyone starts using software with the default settings.

I'd even go a step further and say when someone starts using a source code
version management software the first thing they do is give it a go and
check out and in again pretty much everything they got scattered around
their harddrive and every memory stick in reach. ;)

The least I'd expect is that these files are not just silently uploaded but
that I'd receive a message, explaining why they are uploaded. I thought I
got to chuck the box out the window after I'd been asked again so many time
to enter a commit note including all the files I didn't want it to include.
Bear in mind, I explicitely told the software not to upload them, but it
secretly ignores/drops my command. That is far from being user-friendly. ;-)

Of course I'm glad to know now how to circumvent this issue.
Thanks again.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Mon, Apr 10, 2017 at 2:57 PM, Thomas <tho...@dateiliste.com> wrote:
> I reckon I owe you a beer! ;-)

Not at all. I don't drink, anyway. Well, not beer. :)

I was surprised my first guess was off base, but actually sitting down
and trying some stuff outside the large repo you're using was useful
to see how things worked.

> Anyway, your suggestion sounds very reasonable (ok, it doesn't sound
> reasonable at all to be honest, but I think that's what happened).

I think if you add a file to a repo then add an ignore, it is safer to
keep maintaining it rather than suddenly ignoring it. The two events
are conflicting, so fail safe. Removing the file allows it to be
ignored going forward.

> After reading your mail I remembered that all files that have been ignored
> all along via ignore-glob or --ignore are files I deleted manually at one
> point or another.
>
> The files that always go into the repro I've never touched but I'd added
> them to the ignore list later.

Glad I was able to point you in a useful direction.

FYI: In looking a little at the code, I can see that there was some
work related to versioned settings a couple years ago now that seems
to have been put in place to check either the file in the repo or the
file on the disk depending on what is available. I don't have time to
understand it completely, but that seems to be the source of my
confusion as to when / where versioned settings are accessed / read.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Mon, Apr 10, 2017 at 1:58 PM, Thomas <tho...@dateiliste.com> wrote:
> On 2017-04-10 20:34, Scott Robison wrote:
>>
>> On Mon, Apr 10, 2017 at 1:05 PM, Thomas <tho...@dateiliste.com> wrote:
>>>
>>> On 2017-04-10 20:00, Scott Robison wrote:
>>
>> Let's say you have a repo named bob. You have not yet committed any
>> .fossil-settings files. You create the .fossil-settings files then run
>> addremove and commit. The addremove command will not recognize any of
>> the files you are ignoring at this point because you've never
>> committed the .fossil-settings files themselves.
>
>
> Thanks for your extensive explanation. You're right, I would have never
> expected it to work like this. In fact, I believe if it really behaves as
> you described it, that's something that should be mentioned in the
> documentation.
>
> I can't imagine I'd be the only or first one who'd stumble over this. It
> means that whatever you do or want to do the first commit automatically
> stores all files unconditionally in the repository.
>
> I'd even go as far as to say this defeats the whole idea of having (only)
> these files in the first place. Or, in other words, what good is an
> exclusion or filter list that doesn't exclude or filter right from the
> start?
>
>
>> If you *are* doing this, maybe you would be satisfied with a flow like
>> this:
>>
>> 1. update .fossil-settings
>> 2. add (if necessary) and commit those changes
>> 3. now run addremove for the entire working copy
>> 4. now commit those changes.
>
>
> I am using these files at the moment, yes.
>
> But even before the first addremove or commit I had the .VC.db or .tlog
> files exluded with the --ignore parameter on the command line for addremove.
> So, no this behavior can't be the reason why Fossil ignores some files but
> not others.
>
> fossil addremove
> and
> fossil commit
> must have been run hundreds of times now, and the files are still updated in
> the repository every time addremove is performed.

I'm running on very little sleep, so I hope I'm helping more than just rambling.

Anyway, I just created an empty test repo:

> fossil init test.fossil

then opened it

> fossil open test.fossil

then created three files

> echo '*.a' > .fossil-settings\ignore-glob
> echo a > a.a
> echo b > b.b

then ran fossil addremove and it only added b.b. My guess is that
since I last cared about that bit of functionality, someone changed it
to work more intuitively.

Given that .fossil-settings\ignore-glob is in a hidden dot folder,
addremove does not automatically add the ignore-glob file itself. I
did that separately.

Next I added a.a explicitly (it warned me and I said okay) and
committed. Then I made a change to a.a and it was identified as a
change for the next commit.

So my best guess at the moment is: During one of your earlier attempts
at adding things, you added a bunch of files and committed them to the
repo. Now that those files are in the repo, fossil will not ignore
them because they are part of the repo. If you were to remove the
files from the work directory so that fossil was no longer tracking
them, commit those changes, then try addremove again, it might work
more to your liking.

At least, that worked for me here with a simple little repo with only
a few files in it.

My version: "This is fossil version 2.1 [83e3445f67] 2017-03-10 17:07:08 UTC"

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Mon, Apr 10, 2017 at 1:05 PM, Thomas <tho...@dateiliste.com> wrote:
> On 2017-04-10 20:00, Scott Robison wrote:
>>
>> On Apr 10, 2017 12:48 PM, "Thomas" <tho...@dateiliste.com
>> <mailto:tho...@dateiliste.com>> wrote:
>> Example of .fossil-settings\ignore-glob:
>> *.obj
>> *.tlog
>> *.VC.db
>>
>> The real file of course contains a much bigger list. I only picked
>> these three masks as an example.
>>
>> Fossil happily ignores the .obj files (and many others), but no
>> matter how hard I try, it keeps adding all .tlog and all .VC.db
>> files (and it ignores many others too). I can't figure out a pattern
>> that would tell me why some files/filters are accepted and work as
>> advertised in the ignore-glob, others aren't.
>>
>> Is there anything I overlooked?
>>
>> Any help or idea is highly appreciated.
>>
>>
>> I think it reads those from the repo, so you won't see anything until
>> you've committed the files once or after changes are made.
>
>
> The files it ignores (.obj, .iobj, etc) are neither in the local repository
> nor in the remote one.
>
> The files it doesn't ignore (.VC.db, .log, .tlog, tec) are in both, the
> local and the remote repository.
>
> I got autosnyc on. Sorry, I probably should have mentioned this.

No problem, I was more brief that I maybe should have been because I
was just about to head into a meeting. So here is what I was trying to
say:

Let's say you have a repo named bob. You have not yet committed any
.fossil-settings files. You create the .fossil-settings files then run
addremove and commit. The addremove command will not recognize any of
the files you are ignoring at this point because you've never
committed the .fossil-settings files themselves.

Let's say you have set some glob patterns in the past, either through
the web interface, the command line, or via a .fossil-settings file.
Then you update the .fossil-settings files, run addremove and commit.
Any changes you made to the .fossil-settings files will not be honored
because you've not committed them.

It very well may be that this is not what you are doing, but I can see
how it would not be intuitive that fossil will not use the
.fossil-settings file you have updated in the opened working copy but
not yet committed.

If you *are* doing this, maybe you would be satisfied with a flow like this:

1. update .fossil-settings
2. add (if necessary) and commit those changes
3. now run addremove for the entire working copy
4. now commit those changes.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Scott Robison]

On Apr 10, 2017 12:48 PM, "Thomas"  wrote:

Hello,

As stated in one of my earlier mails, I also got an issue with files to
ignore.

I have now created a folder .fossil-settings and placed the glob files in
it.

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).

Before, the batch file read the external files with the
crlf/binary/exclusion masks and created command line arguments, separated
by commata, now it just writes its output to the mentioned files in
.fossil-settings, each file mask on a different line.

The outcome is exactly the same. Some files are added to the repository
every single time although their - in my opinion - correct name masks are
in correctly added to ignore-glob.

Example of .fossil-settings\ignore-glob:
*.obj
*.tlog
*.VC.db

The real file of course contains a much bigger list. I only picked these
three masks as an example.

Fossil happily ignores the .obj files (and many others), but no matter how
hard I try, it keeps adding all .tlog and all .VC.db files (and it ignores
many others too). I can't figure out a pattern that would tell me why some
files/filters are accepted and work as advertised in the ignore-glob,
others aren't.

Is there anything I overlooked?

Any help or idea is highly appreciated.


I think it reads those from the repo, so you won't see anything until
you've committed the files once or after changes are made.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with crlf-glob *

[Scott Robison]

On Apr 8, 2017 3:29 PM, "Thomas"  wrote:

On 2017-04-08 21:59, Richard Hipp wrote:

> On 4/8/17, Thomas  wrote:
>
>>
>> C:\fos>fossil settings crlf-glob *.obj
>> C:\fos>
>> C:\fos>fossil settings crlf-glob *
>> Usage: fossil settings ?PROPERTY? ?VALUE? ?-global?
>> C:\fos>fossil settings crlf-glob * -global
>> Usage: fossil settings ?PROPERTY? ?VALUE? ?-global?
>> C:\fos>fossil settings crlf-glob "*"
>> Usage: fossil settings ?PROPERTY? ?VALUE? ?-global?
>> C:\fos>fossil settings crlf-glob "*" -global
>> Usage: fossil settings ?PROPERTY? ?VALUE? ?-global?
>>
>> Does anyone know how to unveil the secret of getting the mentioned
>> asterisk into the crlf-glob setting without consulting the web interface?
>>
>
> This seems to be a windows shell thing.  On unix, you would just put
> the * inside single-quotes: '*' - but that appears not to work on
> windows.  I don't know the solution.
>
> A hint:  You can run
>
> fossil test-echo *
>
> to see what the command-line gets expanded to by the shell.  I haven't
> (yet) found a variation on this that does not expand the *.
>
> Anybody else?
>

Thanks for this quick reply. I think I understand it now.
However, it's still quite weird.

C:\fos>fossil test-echo *
g.nameOfExe = [C:\fos\fossil.exe]
argv[0] = [fossil]
argv[1] = [test-echo]
argv[2] = [_FOSSIL_]
argv[3] = [fossil.exe]
argv[4] = [db.fossil]
argv[5] = [test.cmd]

Is this what it's supposed to look like?

test.cmd contains:
ECHO %1

When I run it:
C:\fos>test.cmd *

C:\fos>ECHO *
*

So, it works for test.cmd but not for Fossil.


Windows (and DOS previously) include simple command prompts as compared to
posix. They do virtually no command line processing, leaving it to each
program to process the command as it wants. So Windows does pass the
asterisk to fossil. The C run time start up code expands the asterisk
before passing control to fossil's main function.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Couple of beginner questions

[Scott Robison]

On Thu, Mar 30, 2017 at 3:17 PM, Ross Berteig <r...@cheshireeng.com> wrote:
> The large part of the world stuck with MS products can and should exert some
> pressure to get better compliance from MS with many standards, not just
> Unicode. They change at glacial speeds, but they do change. A good first
> step would be for them to develop and support a "proper" Unicode Locale and
> code page for their console window. Doing that right likely means following
> the examples and lessons learned from the Linux community which has been
> blazing that trail and found (and escaped) most of the dead ends. I think it
> has become clear that Unicode is here to stay, and UTF-8 is the best
> representation of it both at rest in files and on the wire in protocols.

I agree completely about MS doing things Better(TM), but when it comes
to complaints or observations about their Unicode compliance, I laugh.
Not because they shouldn't change ... they should. But because they
were one of the *first* to support Unicode as designed and
standardized. UTF-8 was people blazing new trails because they didn't
want to do it in the blessed manner of the day. :) Unicode was a
simple straightforward two byte encoding back then. As Bill Gates
(then CEO of MS, MS being one of the earliest members of the Unicode
Consortium) said in 1991:

"Okay, so 640K of RAM isn't enough memory, but 64K code points will
definitely encode more characters than we'll ever possibly need. You
have my word on it!"

True story. ;)

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] update Fossil performance chart?

[Scott Robison]

On Wed, Mar 29, 2017 at 9:46 AM, jungle Boogie  wrote:
> On 28 February 2017 at 08:04, jungle Boogie  wrote:
>> Hi All,
>>
>> This is most likely a request only Dr. Hipp can fulfill has he has
>> access to all the databases.
>>
>> Is it possible for this chart to be updated?
>> https://www.fossil-scm.org/index.html/doc/trunk/www/stats.wiki
>
> That chart is now two years and a month out of date. Can it be updated?

I started to update the wiki page myself, but as I don't have access
to the th3 repository, I can't update it. However, I did gather the
rest of the information, so here it is:

project #artifacts #checkins duration  uncompsz  reposz
ratio clonebw
sqlite  70,32518,5296,149 4,857,934,127  62,996,480
77:1  50,099,900
tcl151,06320,5636,944 7,269,055,159 206,233,600
35:1 134,189,804
fossil  36,65410,5083,540 3,344,624,100  39,493,632
84:1  25,687,806
slt  2,358   1613,043 2,120,447,782 145,661,952
14:1 143,053,938
SQLite Docs  7,567 2,3393,426   290,092,771  13,713,408
21:1  10,797,106
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil interprets plain-text file as a binary file

[Scott Robison]

On Mar 27, 2017 6:44 PM, "Byron Sanchez"  wrote:

Recently, however, fossil has started interpreting one of these org-mode
files as a binary file. Now, fossil prompts with it's binary-file warning
each time I update the file. In addition, this file can no longer be diffed
in the web interface, since fossil believes it to be a binary file.

I'm wondering what steps I should take to debug this, or if there are any
common causes for this sort of thing? Very long lines perhaps or possibly
unicode characters?


Long lines, invalid unicode sequences, or many control codes.

What type of data is it? Source code, poetry?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Scott Robison]

On Mar 26, 2017 11:25 AM, "Christophe Gouiran" 
wrote:

Please find as attached file another patch which:

   1. First test for a real terminal before spawning the pager command.
   2. No more paginate json command.

I see that most of you complain about this proposed feature.

It was only a proposition, if it is not accepted I won't care.

However, it would be possible to make both world happy:

   1. Those who don't like this feature simply don't set a pager-command
   setting.
   2. Those who want to use it set a pager-command setting.

And, IMHO adding or removing a '|' at the end of command names is not a
maintenance nightmare.

I'm sorry if I've offended. My point was that one code path that works with
all future commands or changes to commands is not bad, even if it is not
something I will personally use. Needing to tweak code paths unrelated to
DVCS functionality to maintain this feature going forward seems less than
ideal.

I do commend you for stepping forward to implement it. I just disagree with
the idea of making it command specific.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Scott Robison]

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 to
a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:


{snipped list of commands}

I appreciate what you're trying to do here, but what you've done (based on
your description) is create a maintenance nightmare (or headache at
minimum). Your implementation will forever need to be tweaked when new
commands are added or existing commands changed in some way that changes
their amount of output, perhaps based on some extra parameter. DRH
suggested that it should be based on any output, which would avoid the
worry about how fossil changes over time.

I'm coming around to the position that, given the ease of typing "| pager"
when desired, or defining an alias or using a wrapper of sorts, this
feature may be a mistake. I've never once wished that fossil had done this
for me, though I could be in the minority.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Scott Robison]

I don't know about what commands to paginate by default, but no to
versionable settings for this. Don't want to force this on others.

On Mar 23, 2017 4:08 PM, "Christophe Gouiran" 
wrote:

> Good morning,
>
> I would like to implement the feature given in the title.
> I'm inspired by what Git (by default ?) and Mercurial (with Pager
>  extension activated)
> do.
>
> I'd like to avoid typing "fossil  | less" everytime I notice it
> produces an output which doesn't fit in a single screen.
>
> Find below my ideas (in no particular order).
>
> Settings :
>
>1. Add a new boolean setting "Paginates commands" (it is true by
>default)
>2. Add a new string setting "pager-command" (it is empty by default)
>3. Add a new string setting "Commands to paginate" (default value to
>be defined)
>
> If pager-command is empty then following pager command will be used:
>
>1. "more" under Windows.
>2. "less -FRSX" under any other OS.
>
> When Fossil writes something to its standard output, then it is sent
> through the pager if (and only if) all following conditions are met:
>
>1. Fossil standard output is a real terminal.
>2. "Paginates commands" setting is true.
>3. Executed command is indicated in "Commands to paginate" setting.
>
> *Fossil standard error must not be paginated.*
>
>
> Now I'm waiting for your advices/improvements/feedbacks.
>
> For example:
>
>1. Should the settings be versionnable ?
>2. Which commands to be put by default in "Commands to paginate" ?
>
>
> Many thanks in advance for taking the time to participate.
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is Fossil Hash-collision proof?

[Scott Robison]

On Mar 21, 2017 11:04 PM, "Martin Vahi"  wrote:



I haven't encountered any collisions yet, but
I was wondering, what will happen, if 2 different
files that have the same size, same timestamps,
different bitstreams, but the same hash (regardless of hash algorithm)
were to be committed simultaneously, at the same commit?


Let's say for the sake of argument that you somehow wind up with two
modified files in the same commit that have the same hash but different
contents. Fossil will read back the data it just wrote to ensure what went
into the repo can be correctly retrieved. One of the two files will fail,
and fossil will refuse to commit the data will a message. At that point you
can change a file in some little way to get past the problem.

In any case, fossil won't allow you to commit two files with the same hash
given its verification steps.


After all, it's the "improbable" corner cases that
accumulate and trash even those projects that are
not slammed together by sloppy-or-just-lacks-the-self-esteem-to-care
type of developers. Everything works fine for a
long-long-long period of time, until one day, in the midst
of being overwhelmed with some other task that
uses software X as one of its main tools...

Thank You.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Support for commonmark markdown in fossil

[Scott Robison]

On Sat, Mar 11, 2017 at 8:08 AM, Mark Janssen  wrote:

> Good questions. Currently it replaces the existing markdown parser which
> can break existing files. This is why I suggested the repo wide setting.
>
Sorry, I missed that part.

> There are other possible solutions (switch on extension being one as well)
> but having different markdown flavours in one repo just feels wrong to me.
>
I'm torn on the two. I think I'd prefer the repo wide setting myself, or
even just replacing wholesale, but I can appreciate why people who've
already starting using the existing markdown might not like that. Switching
on an extension feels ugly to me, but it would allow people to gradually
change their repo over to using commonmark over time rather than having to
do it all at once.

In any case, I'm all for it.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Support for commonmark markdown in fossil

[Scott Robison]

On Sat, Mar 11, 2017 at 7:07 AM, Mark Janssen <mpc.jans...@gmail.com> wrote:
>
> My question to you all is, would there be any interest in adding
> commonmark support?
>

I like the idea of a more fully featured markdown implementation. Would
this replace the existing markdown support or be in addition to it? If
replace, would it "break" existing repos that are using markdown? If people
have .md files with the existing markdown support, might this need a
different extension?

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about the file formats.

[Scott Robison]

On Dec 20, 2016 10:59 PM, "John Found"  wrote:

Well, the compression is the last thing I am talking about. It is
important, but not essential.

I am talking about several people working on one file and then fossil
merging the
changes automatically (of course if there is no conflicts in the edits).


I think the answer to your question is that merging depends on a knowledge
of the structure of data in order to detect where conflicts do or do not
exist. The structure of text files is "an ordered sequence of variable
length records" and the merge algorithm sees non overlapping changes as
independent. This is not always true, but it works often enough to be
useful. Because it is not always true, it is important to test post merge &
pre commit.

The merge algorithm could be modified to work with other data structures
but it would still require the property that non overlapping changes be
independent (have no impact on previous or future data). With a "binary"
format there are many other things that could go wrong. Fixed length
records, specific requirements for alignment, embedded non symbolic
references to other parts of the file are the first few that come to mind.

Without specific knowledge of the structure of the data, merge can't work.
Even with knowledge of the structure of text files, it can still get things
wrong.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Download v1.36 Linux x86 tar.gz actually contains 64bit binary

[Scott Robison]

On Nov 11, 2016 5:28 PM, "K. Fossil user" 
wrote:
>
> Ah you don't understand again what I've said ...
>
> 1/ Fossil and SQLite work together, and to be clear, the same guy work
for both projects.
> I was even told that the AIM of Fossil is to help SQLite.
> Do you agree at least with these ?

Yes, fossil & sqlite have a beneficial symbiotic relationship.

> 2/ When you plan things you are supposed to create a Gantt chart or
something which help any project.
> For instance, something serious not something else.
> You've said it : Oct 24 Fossil, Nov 04 SQLite.
> I AM SO happy that you've wrote it.

I have no idea what you think I wrote. Gantt charts are not requirements
for successful software. I've written some very successful software
projects that have been recognized with industry awards without ever using
a gantt chart. DRH makes new fossil releases periodically for the community
but he generally suggests using the tip of trunk as he usually does himself.

> Explain me why a SO serious project could not wait for 10 days or if it
is not that possible (I don't see why ??), why don't Fossil create a 1.36.1?

Fossil has never used semantic versioning. I don't understand the reason
for your continued emphasis on 10 days. Perhaps the reason is that people
are imperfect, or that they have different priorities than you, or that
they have simply started blocking your emails due to the in your face "I'm
right and anyone who disagrees with me is a fool" style attitude that comes
across in your messages. No, that is not a quote from you, but it is how
you come across.

There are ways to communicate that invite people to see your point of view.
There are other ways to communicate that make people dislike your message
no matter how correct it might be.

>
> [too much] Pride ? Huh ?
>
> My point was : Why do Fossil show a 1.36 FEW days BEFORE SQLite.
> (FEW days IS the key of MY point of view before yours)

I believe I addressed this above.

>
>
> Best Regards
>
> K.
>
>
> 
> De : Luca Ferrari 
>
> À : Fossil SCM user's discussion 
> Envoyé le : Vendredi 11 novembre 2016 11h38
> Objet : Re: [fossil-users] Download v1.36 Linux x86 tar.gz actually
contains 64bit binary
>
> On Wed, Nov 9, 2016 at 4:16 PM, K. Fossil user
>  wrote:
> > Beyond that, I don't understand why SQlite is not 3.15.1 ...
>
> Seems to me that SQLite 3.15.1 was released on november the 4th, while
> fossil 1.36 was compiled on october the 24th.
>
> Anyway, I cannot find checksums for 1.36 here
> .
>
> Luca
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] features I'd like to have in fossil

[Scott Robison]

> If you color lines by meaing, it is easier to understand:

Unless you're color blind, in which case it might be impossible to
understand.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] on sha1 as a hash

[Scott Robison]

On Wed, Oct 19, 2016 at 2:36 AM, Aldo Nicolas Bruno <ovenpa...@pizzahack.eu>
wrote:

> Better question can be, how fossil manage collisions?
>

Fossil rejects new artifacts with matching hashes, working on the
assumption that it already has the blob. The only way someone could hope to
exploit this for malicious purposes is:

1. Discover some fossil user has created a commit with an artifact having a
given hash X.
2. Quickly create another artifact with that same hash.
3. Push it to other copies of the same repository before the original
fossil user is able to push his copy.

In both the cases of git and fossil, it seems to me that hash collisions
(deliberate or coincidental) are a race condition. Whoever pushes to other
repositories first wins.

Given that it is impossible to predict exactly how one will solve a given
problem (and thus what its hash would be) in advance, the speed of fossil's
default auto sync, the fact that no one has yet demonstrated an effective
real time attack, and the fact that sha1 is not being used for security but
for reliability, sha1 isn't an issue.

Even if someone found an effective real time attack that could generate a
collision, they then have the problem of not just finding a collision, but
a collision that will be close enough to the original that the primary
functionality wasn't broken (in the case of tracking source code, arguably
the most common case).

Really, from this POV, fossil and git are both just fine. It's far more
likely that someone will compromise a server with a weak password and
completely replace the good repo with a bad repo, or just host a fork that
looks legit and get people to pull from that instead.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] disabled due to excessive bounces (again?)

[Scott Robison]

On Oct 16, 2016 6:35 PM, "K. Fossil user" 
wrote:
>
> I am angry because Fossil knows nothing about marketing which is bad for
any project...

If I may paraphrase, Fossil's benevolent dictator has stated many times in
the past that the One True Purpose (TM) of Fossil is to serve SQLite
development. The fact that others find it nice for their use is a happy
coincidence.

I think the point of marketing can be interpreted a couple different ways.

One, in some organizations marketing drives development. This is done to
make more money or to try to be all things to all people. Since Fossil is
FOSS money is not an issue. Since DRH has a pretty clear vision of what he
wants Fossil to be, he explicitly does not want it to be all things to all
people. He's not opposed to allowed enhancements that he doesn't use
himself as long as they don't conflict with his core DVCS principles.

Two, pure marketing, from the perspective of informing people of the
option, is not a strength of most FOSS projects. Evangelism is similar but
different. I would state that Linus Torvalds isn't a great marketer either,
but that didn't stop the Linux kernel from gaining mind share. It just
happened to come at the right time and became huge IMO based on the FUD
surrounding BSD at the time. That git is popular is almost exclusively an
artifact of Linux popularity, not brilliant marketing.

In similar fashion, SQLite started as a solution to a problem it's author
was having. It was shared, and it grew in popularity. From a dev
perspective it's arguably not as interesting as Linux (there are more
subprojects of Linux for a dev to try to hack on if they want), but it has
gained mind share in its space. The fact that SQLite is a smaller scope
project than Linux parallels the relative mind share of Fossil vs git. Not
to mention the cottage industry of projects that exist to make git more
usable, which is arguably not as necessary for Fossil.

I don't believe you're trying to be offensive in your use of words, but I
have a hard time understanding how you think one email address having
difficulty with a mail list is a sign of a lack of marketing acumen. I
doubt it is a problem many people have. Would it drive away people?
Perhaps. Has it? It doesn't appear to have, but maybe this mail list is
preventing more people from engaging with the project than we realize.

If I might make a suggestion. Try creating a non Yahoo email account.
Subscribe from it. Configure it to forward to your Yahoo account, or to
have Yahoo pull from it. See if that solves the problem. Don't attribute
malice or incompetence. I think everyone would like things to just work,
but they don't always, and there can be too many variables for one person
to analyze in finding a solution.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Files named "AUX" on Windows

[Scott Robison]

On Wed, Oct 5, 2016 at 10:03 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Wed, 5 Oct 2016 09:37:23 -0600
> Warren Young <w...@etr-usa.com> wrote:
>
> [...]
> > 2. Contrast almost every Unix system, where the only illegal
> > character in a file name is the forward slash.
>
> ...and NUL, I beleive.
>

Not to be confused with the DOS/Windows NUL device. :)

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Files named "AUX" on Windows

[Scott Robison]

On Tue, Oct 4, 2016 at 10:22 AM, Pierpaolo Bernardi <olopie...@gmail.com>
wrote:

> On Tue, Oct 4, 2016 at 6:15 PM, Richard Hipp <d...@sqlite.org> wrote:
> > See https://www.fossil-scm.org/aux-test/doc/trunk/aux.md
> >
> > Apparently if a Fossil repository contains a file whose basename is
> > "aux", then an attempt to open or check-out that repo fails with an
> > error.  Only the basename needs to be "aux".  The full name can be
> > things like "src/aux.c" or "doc/aux.txt".
> >
> > Does anybody know of a reasonable work-around?
>
> According to this page, it looks like it can be done:
>
> https://blog.onetechnical.com/2006/11/16/forbidden-file-and-
> folder-names-on-windows/
>
> But in practice these are forbidden names in windows, the only
> reasonable path is to rename these files to something else.
>

We could modify the Windows code to use the \\.\ prefix trick and then
fossil could create / delete the files. If we did that, how much pain would
it cause to other tools and processes on the Windows system?

If we don't support it, Fossil potentially looks bad to someone for not
creating what appear to be ordinary file names. If we do support it, Fossil
potentially looks bad for creating files or directories that other
processes can't interact with normally.

I wouldn't mind taking a stab at it if enough people think it is
worthwhile, but I'm not sure it is worthwhile.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Unversioned files.

[Scott Robison]

On Sun, Sep 11, 2016 at 3:27 PM, Adam Jensen <han...@riseup.net> wrote:

> On 09/11/2016 04:42 PM, Scott Robison wrote:
> > I may not be understanding you, but from my point of view, it already
> > does what you want by supporting versioned files that you simply never
> > change. For example, you could have a repo that has a structure along
> > the lines of:
> >
> > /root/static-data/ -> a place to store lots of big binary blobs that you
> > don't intent to ever modify.
> >
> > /root/dynamic-data/ -> a place to store things that you want to track
> > the history for
> >
> > Is this inadequate? If so, how or why?
>
> My impression is that with a different class of files, the operations,
> interface, and underlying implementation can be specialized for the
> qualities, characteristics, and various needs that are peculiar to that
> class. For example, an unversioned file might avoid some of the CPU,
> memory, and/or storage requirements that are involved in versioned
> files. Also, I imagine there might be some specialized commands and
> alerts associated with the two major use-cases for unversioned files
> (critical immutable data, and temporary intermediate data).
>

You are generally correct that a specialized solution can often improve on
the generalized solution by some metric. There are ways to do things with
huge files (such as diff them) that wouldn't strictly require as much
memory as the general case does, but the utility is marginal at best for
fossil's design case. Very few people would have a need to compute deltas
for a terabyte sized file, so it is not implemented. Not that you were
suggesting someone should be able to do that, I was just going for the
first very ridiculous idea that came to mind.

In any case, it might be possible to make the unversioned functionality
"better" in some way, but it seems like a less than ideal use of time IMO.
Fossil already handles the critical file tracking for versioned files, just
don't overwrite them. And if at some point you discover that the critical
data really is wrong or outdated, you can commit a new version over the old
one. In essence, the unversioned critical data functionality you've
envisioned works off the assumption that you can see into the future and
guarantee you'll never change your mind about the utility of versioning for
these files. YMMV

As SB said, it's just an opinion, and not one that drives the project. I
just wanted to try to understand what you were hoping to gain from it, so
thanks for answering my questions.


>
> Ultimately, I suppose the purpose of a tool like Fossil is to assist in
> the management of complexity. Differentiation and specialization seems
> like a fundamental part of that. But yeah, my tests all currently make
> use of the versioned file class for storage.


Of course, adding differentiation and specialization increases complexity,
so it can be a tricky balancing act.
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Unversioned files.

[Scott Robison]

On Sun, Sep 11, 2016 at 1:49 PM, Adam Jensen <han...@riseup.net> wrote:

> On 09/11/2016 01:54 PM, Stephan Beal wrote:
> > On Sep 11, 2016 18:18, "Adam Jensen" <han...@riseup.net
> > <mailto:han...@riseup.net>> wrote:
> [snip]
> >> '''
> >> 5.4 Unversioned File Sync
> >>
> >> "Unversioned files" are files held in the repository where only the most
> >> recent version of the file is kept rather than the entire change
> >> history. Unversioned files are intended to be used to store ephemeral
> >> content, such as compiled binaries of the most recent release.
> >> '''
> >>
> >> The phrase "ephemeral content" is a bit disconcerting. It suggests
> >> values and attitudes towards this data which will probably be reflected
> >> in the requirements, specification, and implementation of the software.
> >>
> >> In the use-case I have in mind, this data would be "immutable content"
> >> and should be considered precious.
> >
> > That's not, as i understand it, the intention of unversioned filed.
> > Anything "important" needs to be checked in (versioned). Unversioned
> > files are primarily intended for hosting pre-built binaries and such.
>
> We might not be intersecting on this point; a perspective difference, I
> suspect. What I am suggesting is that the current intention of
> unversioned files might need be slightly tweaked to encourage an
> additional use-case where the repository supports the organization and
> management of critical data (immutable; a snap-shot of reality; large
> binary files) in addition to highly revised text files such as data
> analysis scripts, annotations, and documentation. Use of the unversioned
> files facility for storage and management of fleeting, intermediate
> files is also valuable. Quoting Chancellor Palpatine, I suggest we
> "embrace...a larger view" of unversioned files.
>
> On the other hand, it is still unclear [to me] if Fossil can be used
> this way. Once more complete unversioned files functionality is
> available, I can answer some of my questions through tests of the
> system. The critical points of interest are:
>
> 1. Maximum single unversioned file size.
> 2. Repository performance and integrity as overall size increases.
> 3. FuseFS performance.
> 4. Sync performance/reliability/usability.
>
> Once I have a better idea of these various characteristics and
> constraints, then it should be possible to estimate where Fossil might
> be a reasonable solution and where some other approach is needed.
>

I may not be understanding you, but from my point of view, it already does
what you want by supporting versioned files that you simply never change.
For example, you could have a repo that has a structure along the lines of:

/root/static-data/ -> a place to store lots of big binary blobs that you
don't intent to ever modify.

/root/dynamic-data/ -> a place to store things that you want to track the
history for

Is this inadequate? If so, how or why?

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

[Scott Robison]

On Thu, Aug 18, 2016 at 2:06 PM, Warren Young <w...@etr-usa.com> wrote:

> On Aug 17, 2016, at 5:21 PM, Kain Abel <isoru...@gmail.com> wrote:
> >
> > A former ;) git user would
> > lose the stash without asking if he uses close
>
> You misunderstood my responses above, then.  Fossil tells you that closing
> the repo will remove the stashes, if any are present, and refuses to
> continue unless you pass --force.
>
> This isn’t so much accidentally shooting yourself in the foot as it is
> cocking the hammer taking aim before shooting yourself in the foot. :)
>

Hold on, you mean fossil expects me to read the output to understand the
current state and status of commands issued? That's pretty user
unfriendly...

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compiler warnings

[Scott Robison]

On Aug 2, 2016 9:12 AM, "Richard Hipp"  wrote:
>
> On 8/2/16, Ron W  wrote:
> >
> > Are there really still compilers in use
> > that don't implement C99?
> >
>
> I still build Fossil on a circa-2002 iBook.  (See section 4 of
> http://fossil-scm.org/fossil/doc/trunk/www/build.wiki).  I do not know
> if it implements C99 or not, but if I had to guess I would say "not".

Plus SQLite is built on a number of obscure platforms where there may not
be a selection of tools. What would C99 standards compliance give the
project that it doesn't have with C89?

> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] false positive UTF-8 test

[Scott Robison]

What version of fossil are you using? Some changes have been made fairly
recently that you may not have.

On Jul 19, 2016 1:16 AM, "Svyatoslav Mishyn"  wrote:

> Hello,
>
> I'm using Fossil to store GPG encrypted passwords;
>
> and one file Fossil detects as UTF-8:
>
> /home/juef/tmp: f test-looks-like-utf abc.gpg
> File "abc.gpg" has 631 bytes.
> Starts with UTF-8 BOM: no
> Starts with UTF-16 BOM: no
> Looks like UTF-8: yes
> Has flag LOOK_NUL: no
> Has flag LOOK_CR: yes
> Has flag LOOK_LONE_CR: yes
> Has flag LOOK_LF: yes
> Has flag LOOK_LONE_LF: yes
> Has flag LOOK_CRLF: no
> Has flag LOOK_LONG: no
> Has flag LOOK_INVALID: yes
> Has flag LOOK_ODD: no
> Has flag LOOK_SHORT: no
>
> If someone want to get that file, I will send it.
>
> Also I have .fossil-settings/binary-glob (with *.gpg) in the repository.
>
>
> --
> https://www.juef.tk/
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Web comment editor transforms LF into CRLF

[Scott Robison]

On Fri, Jun 17, 2016 at 6:04 PM, Warren Young <w...@etr-usa.com> wrote:

> On Jun 17, 2016, at 1:59 PM, Scott Robison <sc...@casaderobison.com>
> wrote:
> >
> > Would it be a bad thing to just settle on LF only going forward, always
> stripping CR?
>
> The argument over canonicalizing all text input to LF has been had here
> before — with me as at least one of its proponents — but I did not get the
> sense that the proposal was getting much traction.
>
> But what the hey, I’ll make another stab:
>
> For any blob data that Fossil considers “text,” why not strip all CRs on
> ingest, then based on either a setting or platform check inject CRs as
> necessary when expelling a copy from the DB?  Then users checking out on
> Windows will see the CRLFs they want, and Fossil doesn’t have to deal with
> CRs appearing and disappearing as different users on different platforms
> edit the same files?
>

Ah. I was just thinking for the text that fossil itself injects, not
something that would impact all blobs. I wouldn't be opposed to that
myself, but I can appreciate why it isn't a desirable thing for fossil to
do.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Web comment editor transforms LF into CRLF

[Scott Robison]

On Fri, Jun 17, 2016 at 1:53 PM, Warren Young <w...@etr-usa.com> wrote:

> While trying to replicate the problem reported in another thread,[1] I
> noticed an odd behavior.  If I edit a comment via fossil ui, then pull the
> change and try to edit it locally with fossil amend, Vim shows ^M
> characters at the end of every line, implying that Fossil UI has
> transformed the LF line endings in the original comment into CRLF.
>
> I haven’t seen this until now because I always check in via the command
> line with EDTIOR=vim (because Vim is the One True Editor) but always in the
> past have edited comments via Fossil UI.  Today was the first time I tried
> fossil amend -e.
>
> According to the Internets[2], this is specified behavior, and is thus
> independent of browser or platform.
>
> I propose that Fossil UI scan the original comment text for CRs, and if it
> doesn’t find any, it should strip them out of the changed comment text
> before storing it in the DB.
>

Would it be a bad thing to just settle on LF only going forward, always
stripping CR?

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Fri, Jun 10, 2016 at 7:10 PM, Joe Mistachkin <sql...@mistachkin.com>
wrote:

>
> Scott Robison wrote:
> >
> > Okay, thanks for all the help. I've committed some new test cases that
> > demonstrate errors in the trunk invalid_utf8. 16 tests fail on trunk,
> > none fail on invalid_utf8_table branch (which of course doesn't mean
> > there aren't bugs, just that the sample data doesn't exercise a buggy
> > path, or that I did something wrong in adding the tests).
>
> Thanks for the new tests.
>
> >
> > But seriously, take a look at the new test cases. Let me know whether
> > you want to tweak your function or want me to merge mine to trunk.
> >
>
> Sure, I'll look at it.  I'm pretty sure we'll go with your function as
> it seems easier to understand and maintain.  Thanks for the bugfixes.


That'd be awesome. Much more satisfying to hack on fossil than some of the
other coding stuff I've done "for fun" in the past!

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Fri, Jun 10, 2016 at 5:24 PM, Joe Mistachkin <sql...@mistachkin.com>
wrote:

>
> Scott Robison wrote:
> >
> > So my expectation that it would automatically update the utf.test file is
> > incorrect? I'm supposed to manually integrate that file back to utf.test?
> >
>
> Yes and yes.
>
> >
> > If I want to specify a new test that should fail but does not currently,
> > am I just supposed to manually tweak the desired expected output of
> > utf-check.txt before integration? That's how it is looking to me at the
> > moment.
> >
>
> Yes.
>

Okay, thanks for all the help. I've committed some new test cases that
demonstrate errors in the trunk invalid_utf8. 16 tests fail on trunk, none
fail on invalid_utf8_table branch (which of course doesn't mean there
aren't bugs, just that the sample data doesn't exercise a buggy path, or
that I did something wrong in adding the tests).

I've updated the invalid_utf8_table branch with performance optimizations.
Profiling the two versions (tip of both trunk & branch), on my machine with
my test data (all possible byte combinations up to 4 bytes in length) says
that mine is now faster. I show the tip of trunk version used about 130
billion cpu cycles vs 112 for the branch version.

HA! ;)

But seriously, take a look at the new test cases. Let me know whether you
want to tweak your function or want me to merge mine to trunk.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Fri, Jun 10, 2016 at 4:23 PM, Joe Mistachkin <sql...@mistachkin.com>
wrote:

>
> Scott Robison wrote:
> >
> > Also: Simply uncommenting the "createTestResults $tempPath 100" call
> doesn't
> > seem to be doing anything for me. Here is what I'm doing:
> >
>
> Here are the steps I just used here locally:
>
> 1. Uncomment the "createTestResults" line.
> 2. Run "tclsh test\tester.tcl fossil.exe utf" from the checkout.
> 3. Results are located in "%TEMP%\utf-check.txt".
>
> If you add extra entries to the array prior to these steps, those new
> results
> should appear in the "utf-check.txt" file as well.
>

Okay, that was very helpful.

So my expectation that it would automatically update the utf.test file is
incorrect? I'm supposed to manually integrate that file back to utf.test?

If I want to specify a new test that should fail but does not currently, am
I just supposed to manually tweak the desired expected output of
utf-check.txt before integration? That's how it is looking to me at the
moment.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Fri, Jun 10, 2016 at 3:27 PM, Scott Robison <sc...@casaderobison.com>
wrote:

> On Fri, Jun 10, 2016 at 12:26 PM, Scott Robison <sc...@casaderobison.com>
> wrote:
>
>> On Jun 10, 2016 6:04 AM, "Jan Nijtmans" <jan.nijtm...@gmail.com> wrote:
>> >
>> > 2016-06-10 10:12 GMT+02:00 Scott Robison:
>> > > FYI, my test code here (C++ harness) consisted of passing every
>> possible
>> > > four byte buffer to the old function and my new function. My function
>> > > identifies the expected number of "strings" as valid UTF-8. I didn't
>> eyeball
>> > > each one to make sure the right ones got through, but getting the
>> exact
>> > > right number is promising to me.
>> > >
>> > > Let me know if you see anything horridly wrong with my code. It's
>> 2am...
>> >
>> > It turns out that your code appears fine, it's just less efficient than
>> mine ;-)
>>
>> You are correct. I was going for correct and readable over fast and
>> wrong. {hides}
>>
>> > There were test-failures but all failures turned out to be errors in the
>> > expected test-outcome. I fixed those test-cases now, added more of
>> > them, and fixed the invalid_utf8() function in trunk. Now all tests pass
>> > with both trunk code and your code.
>> >
>> > Many thanks, Scott !  Once more, fossil got better than it was!
>>
>> Glad it's working. I'm all for faster correct code, too. I had run both
>> implementations through the profiler last night and knew my code was a few
>> percent slower, but figured optimization would narrow the gap when I was
>> alert enough to do more good.
>>
>> I'll take the current code and run it through my ugly test harness and
>> make sure it prints the right numbers in a bit.
>>
>
> The trunk version is still identifying certain sequences as valid. I've
> looked at the utf.test file but can't figure out where to put in cases
> which should fail. Can anyone give me a pointer on this?
>

Also: Simply uncommenting the "createTestResults $tempPath 100" call
doesn't seem to be doing anything for me. Here is what I'm doing:

1. Added four lines to the data array / list / whatever in utf.test
(appended them with numbers 201 through 204).
2. Uncommented the createTestResults call.
3. Change to an empty directory.
4. Run the test harness as "tclsh \dev\fossil\test\tester.tcl
\dev\fossil\win\fossil.exe".

The generated section remains unchanged. I'm probably missing some step,
but I can't figure it out.
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Fri, Jun 10, 2016 at 12:26 PM, Scott Robison <sc...@casaderobison.com>
wrote:

> On Jun 10, 2016 6:04 AM, "Jan Nijtmans" <jan.nijtm...@gmail.com> wrote:
> >
> > 2016-06-10 10:12 GMT+02:00 Scott Robison:
> > > FYI, my test code here (C++ harness) consisted of passing every
> possible
> > > four byte buffer to the old function and my new function. My function
> > > identifies the expected number of "strings" as valid UTF-8. I didn't
> eyeball
> > > each one to make sure the right ones got through, but getting the exact
> > > right number is promising to me.
> > >
> > > Let me know if you see anything horridly wrong with my code. It's
> 2am...
> >
> > It turns out that your code appears fine, it's just less efficient than
> mine ;-)
>
> You are correct. I was going for correct and readable over fast and wrong.
> {hides}
>
> > There were test-failures but all failures turned out to be errors in the
> > expected test-outcome. I fixed those test-cases now, added more of
> > them, and fixed the invalid_utf8() function in trunk. Now all tests pass
> > with both trunk code and your code.
> >
> > Many thanks, Scott !  Once more, fossil got better than it was!
>
> Glad it's working. I'm all for faster correct code, too. I had run both
> implementations through the profiler last night and knew my code was a few
> percent slower, but figured optimization would narrow the gap when I was
> alert enough to do more good.
>
> I'll take the current code and run it through my ugly test harness and
> make sure it prints the right numbers in a bit.
>

The trunk version is still identifying certain sequences as valid. I've
looked at the utf.test file but can't figure out where to put in cases
which should fail. Can anyone give me a pointer on this?



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Jun 10, 2016 6:04 AM, "Jan Nijtmans" <jan.nijtm...@gmail.com> wrote:
>
> 2016-06-10 10:12 GMT+02:00 Scott Robison:
> > FYI, my test code here (C++ harness) consisted of passing every possible
> > four byte buffer to the old function and my new function. My function
> > identifies the expected number of "strings" as valid UTF-8. I didn't
eyeball
> > each one to make sure the right ones got through, but getting the exact
> > right number is promising to me.
> >
> > Let me know if you see anything horridly wrong with my code. It's 2am...
>
> It turns out that your code appears fine, it's just less efficient than
mine ;-)

You are correct. I was going for correct and readable over fast and wrong.
{hides}

> There were test-failures but all failures turned out to be errors in the
> expected test-outcome. I fixed those test-cases now, added more of
> them, and fixed the invalid_utf8() function in trunk. Now all tests pass
> with both trunk code and your code.
>
> Many thanks, Scott !  Once more, fossil got better than it was!

Glad it's working. I'm all for faster correct code, too. I had run both
implementations through the profiler last night and knew my code was a few
percent slower, but figured optimization would narrow the gap when I was
alert enough to do more good.

I'll take the current code and run it through my ugly test harness and make
sure it prints the right numbers in a bit.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Fri, Jun 10, 2016 at 2:04 AM, Scott Robison <sc...@casaderobison.com>
wrote:

> On Fri, Jun 10, 2016 at 1:37 AM, Joe Mistachkin <sql...@mistachkin.com>
> wrote:
>
>>
>> Scott Robison
>> >
>> > Glad to be able to get to something before everyone else for a change.
>> :)
>> >
>>
>> Yes, thank you very much.
>>
>> Also, I know it's not a lot of fun, but...
>>
>> It would be nice if some new tests covering these edge cases were added to
>> the "utf.test" file.  The "generated section" in the file can be created
>> by
>> uncommenting the "createTestResults $tempPath 100" call.
>>
>
> I'm just about to commit and push a branch with a proposed new
> invalid_utf8 function. It will allow the "Modified UTF-8" NUL (C0 80)
> sequence, as well as the CESU-8 & WTF-8 variants described in the same
> wikipedia article. I'm including those because the current invalid_utf8
> function allowed them.
>
> My code isn't quite as efficient (profiler reports 5% diff). But I'm too
> tired to work on it further tonight. Look for "invalid_utf8_table" branch.
> You may very well see some optimization opportunities I haven't yet.
>

Branch committed. I'll run it against the existing test cases later, and
look at spiffing it up.

FYI, my test code here (C++ harness) consisted of passing every possible
four byte buffer to the old function and my new function. My function
identifies the expected number of "strings" as valid UTF-8. I didn't
eyeball each one to make sure the right ones got through, but getting the
exact right number is promising to me.

Let me know if you see anything horridly wrong with my code. It's 2am...

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Fri, Jun 10, 2016 at 1:37 AM, Joe Mistachkin <sql...@mistachkin.com>
wrote:

>
> Scott Robison
> >
> > Glad to be able to get to something before everyone else for a change. :)
> >
>
> Yes, thank you very much.
>
> Also, I know it's not a lot of fun, but...
>
> It would be nice if some new tests covering these edge cases were added to
> the "utf.test" file.  The "generated section" in the file can be created by
> uncommenting the "createTestResults $tempPath 100" call.
>

I'm just about to commit and push a branch with a proposed new invalid_utf8
function. It will allow the "Modified UTF-8" NUL (C0 80) sequence, as well
as the CESU-8 & WTF-8 variants described in the same wikipedia article. I'm
including those because the current invalid_utf8 function allowed them.

My code isn't quite as efficient (profiler reports 5% diff). But I'm too
tired to work on it further tonight. Look for "invalid_utf8_table" branch.
You may very well see some optimization opportunities I haven't yet.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Fri, Jun 10, 2016 at 1:15 AM, Jan Nijtmans <jan.nijtm...@gmail.com>
wrote:

> 2016-06-10 2:01 GMT+02:00 Scott Robison:
> > I just committed
> > a one line fix (with multiple lines of comments to clarify what the code
> is
> > doing in the tricky part).
>
> Scott, I owe you. Many thanks! You are completely right, this was an
> edge-case not covered for.
>

Glad to be able to get to something before everyone else for a change. :)

FYI: There is another problem, I think, with some invalid 4 byte sequences
being accepted (F4 00 80 80, for example). I'm working on a proposed fix.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Thu, Jun 9, 2016 at 6:19 PM, Warren Young <w...@etr-usa.com> wrote:

> On Jun 9, 2016, at 6:01 PM, Scott Robison <sc...@casaderobison.com> wrote:
> >
> > On Thu, Jun 9, 2016 at 2:12 PM, Warren Young <w...@etr-usa.com> wrote:
> > On Jun 9, 2016, at 6:25 AM, rosscann...@fastmail.com wrote:
> > >
> > > The bug:
> > > In lookslike.c, invalid_utf8() returns 'invalid' for the input 0xE0,
> > > 0xB8, 0x94, which is the Thai character 'do dek' (U+0E14).
> >
> > I took a look at that code, and there is no possibility for it to be
> correct.  It doesn’t even try to consider 3- and 4- byte sequences.
> >
> > It does consider 3 & 4 byte sequences in a round about way.
>
> I don’t see that it is checking that the top 2 bits of bytes 3 and 4 are
> 10, the only legal values.
>

Line 162 checks the current byte (c2) and the next byte (c) for validity.
Assuming those checks pass, line 171 sets the next byte c to be a prefix
byte for the next shorter sequence length ((c2 << 1) + 1) (or space if the
valid two byte sequence passed).

The next iteration of the loop uses the "faked" prefix byte and checks the
next byte for validity.

In this case, the old code took:

> 0xE0 0xB8 0x94

Confirmed that c2==0xE0 was a valid prefix byte and that c==0xB8 was a
valid next byte.

Then, instead of keeping the value of c, it reassigns c to ((c2<<1)+1), or
((0xE0<<1)+1) == (0xC0+1) == 0xC1.

The bug is that if a three byte sequence starts with 0xE0, transformed byte
becomes an invalid too short two byte sequence. So my code checks for that
edge case and changes the value to 0xC2.

The next iteration of the loop checks the "forged but okay for our
purposes) value of c2:

> 0xC2 0x94

Confirms that c2==0xC2 is valid and c==0x94 is valid.

Since this is a valid two byte sequence now, it sets the value of c to a
space character, which is always valid utf-8.

It's not intuitive, and I only discovered it after staring at the code for
a while and playing computer with a pencil and paper. I didn't test every
possible byte sequence, of course, but I handful I tried manually now
decode correctly. The only problem I found was with three byte sequences
that start with 0xE0.

Perhaps you will also extend Fossil’s test suite in this area.  A bit of
> Googling turns up these UTF-8 test corpora:
>
>   https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
>   http://www.columbia.edu/~fdc/utf8/


I've never looked at the fossil test suite. I'll see what I can do.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

On Thu, Jun 9, 2016 at 2:12 PM, Warren Young <w...@etr-usa.com> wrote:

> On Jun 9, 2016, at 6:25 AM, rosscann...@fastmail.com wrote:
> >
> > The bug:
> > In lookslike.c, invalid_utf8() returns 'invalid' for the input 0xE0,
> > 0xB8, 0x94, which is the Thai character 'do dek' (U+0E14).
>
> I took a look at that code, and there is no possibility for it to be
> correct.  It doesn’t even try to consider 3- and 4- byte sequences.
>

It does consider 3 & 4 byte sequences in a round about way. I just
committed a one line fix (with multiple lines of comments to clarify what
the code is doing in the tricky part).

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] git quote

[Scott Robison]

An acquaintance tweeted:

I am writing up a quick guide to convert an SVN repo to git, and I actually
typed, "...sensible people never used branches in SVN."

My reply:

@regexer I appreciate why people don't use svn today. I can't understand
why people use git. Fossil, HG, even 7z files! Anything but git!

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] winsymlink branch

[Scott Robison]

On Jun 3, 2016 10:11 AM, "jungle Boogie" <jungleboog...@gmail.com> wrote:
>
> On 31 May 2016 at 01:58, Scott Robison <sc...@casaderobison.com> wrote:
> > Just an announcement in case anyone is using the winsymlink branch
(which
> > seems unlikely to me).
> >
> > I've merged the current trunk into winsymlink. The only functionality
> > exposed in the winsymlink branch, other than what's in trunk, is Windows
> > symbolic links.
> >
>
> Will this be merged into trunk eventually?

That decision is above my pay grade. :) Mapping symlinks to Windows is
Pretty Good, but it's got a few shortcomings:

1. Windows symlinks are only available in Vista & later. It could be a
"surprise" to anyone using Fossil on anything older that Vista. Of course,
the current approach of just writing the link out as a text file with the
link target could be considered unsatisfying as well. The winsymlink branch
deals with this by keeping the current functionality for people who can't
use Windows symlinks for whatever reason (namely writing the link out as a
single line text file).

2. Windows symlinks are not "target agnostic" like posix symlinks are.
Windows symlinks have to know whether they're pointing at a file or a
directory, and should that change, the symlink needs to change. I've
implemented functionality so that "fossil revert" will change the symlink
type should the symlink type change, but it's not obvious to me how to
handle this properly.

3. Not very many people have used the winsymlink branch so it's hard to say
just how robust it really is. In fact, I just discovered an issue that
needs to be addressed related to directory symlinks. There is a bit of a
chicken and egg problem here, in that not a lot of the windows user base is
going to try the functionality until it makes it to trunk, but we don't
want untested / unreliable code in trunk.

4. There is the whole Windows stupidity of not allowing symlink
manipulation in an unelevated command prompt for administrator accounts. It
works if you elevate the command prompt. It works if you don't have
administrator access. It's not a reason in my mind to avoid the winsymlink
functionality, but it certainly makes a person's life more difficult in
Windows.

5. Maybe winsymlink is a solution in search of a problem. I picked it as
something to contribute to Fossil not because I especially needed it, but
because it was a way for me to contribute something that might be useful to
someone and would give fossil feature parity between posix and win32 vs
simply ignoring symlinks on Windows.

I'd love to see it merged to trunk some day, but I'm not comfortable
unilaterally making that decision, nor am I comfortable advising that it is
ready to merge to trunk yet. Given that your question is the first time
this has been asked in months, if not years, demonstrates it isn't a
clamored for feature.

Have you tried it? Have you had problems with it? What is your use case for
symbolic links?

SDR
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] --nosync option for merge, update, checkout when disconnected

[Scott Robison]

On Mon, May 30, 2016 at 2:47 PM, John P. Rouillard  wrote:

> In message 

[fossil-users] winsymlink branch

[Scott Robison]

Just an announcement in case anyone is using the winsymlink branch (which
seems unlikely to me).

I've merged the current trunk into winsymlink. The only functionality
exposed in the winsymlink branch, other than what's in trunk, is Windows
symbolic links.

Carry on.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Sing a song of praise for git {retch}

[Scott Robison]

On Wed, May 18, 2016 at 2:04 PM, Warren Young <w...@etr-usa.com> wrote:

> On May 18, 2016, at 1:31 PM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
> >
> > The fact there are morons among your technical staff is unfortunate
> > (and I sympathize you on this) but this has nothing to do with Git.
>
> From a “rebase doesn’t kill repositories, people kill repositories”
> standpoint, I suppose you are correct.
>
> Nevertheless, it’s been pretty thoroughly argued on this list that the
> arguments in favor of rebase are all either esoteric or wrong, so unless
> you really do have one of those esoteric needs, it’s best to use an SCM
> that doesn’t let you do that.
>
> I will disagree with your characterization of Scott’s coworkers as morons,
> however.  They’re likely technically competent, but they have ignored the
> Spider Man principle: with great power comes great responsibility.  When
> you draw rebase from your git holster in anger, you’d best be prepared to
> take responsibility for everything that happens to all of the clones of
> that repository until they’ve all git-pulled.
>
> I find myself without a good reason to rebase, so I am relieved that I do
> not have to take responsibility for my [mis]uses of it.
>

And they are taking responsibility. The frustrating part for me is that
this is not the first time this has happened. Well, that, and that a
telecommute day turned into a day in the office because I needed to
coordinate with people more closely than I could remotely.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Sing a song of praise for git {retch}

[Scott Robison]

On Wed, May 18, 2016 at 1:31 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Wed, 18 May 2016 13:12:30 -0600
> Scott Robison <sc...@casaderobison.com> wrote:
>
> [...]
> > Yes, I dislike git (though TortoiseGit makes it a lot more
> > tolerable). I don't blame guns when people get shot, or knives when
> > people get stabbed, or cars or alcohol when someone dies in a drunk
> > driving accident. The fact that git has a rebase command doesn't
> > appeal to me, but if other people want to "fix" their history before
> > publishing it, fine. But once it is published leave it the hell alone!
> [...]
>
> When you record a commit, you might be introducing an error in the
> project.  So let's not have the "commit" feature in our VC tools.
>
> The fact there are morons among your technical staff is unfortunate
> (and I sympathize you on this) but this has nothing to do with Git.
>

I pretty much said as much above if you read my email completely. I don't
blame tools when people use them wrong. I still don't like this tool, but I
have definitely been inconvenienced by someone else's improper use of the
tool. Thus I want to take the tool away from them.

I've never ever once had a problem with fossil sync or fossil pull when I
have no uncommitted changes. If I have uncommitted changes, merge may fail.

Using git is like travelling through the multiverse. I'm on Earth-1 and I
clone and checkout version 42 of some repo onto my laptop. The next time I
try to pull updates, I get an error because somehow I'm now on Earth-2
where version 42 never existed.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Sing a song of praise for git {retch}

[Scott Robison]

I had a couple of trouble tickets wind up in my queue at work. We use git.
One of the dependent projects, which I use in a read only fashion, was
apparently out of date, so I did a git pull to get up to date. Lo and
behold, git pull refuses to work because I have uncommitted changes. Except
I never make changes to this project.

Email to dept: "I’m trying to pull SDK and it is complaining that I have
uncommitted changes. I’m sure I’ve never edited SDK. Is this a situation
where someone rebased after I last updated and thus I’m out of sync? Should
I just delete and reclone?"

Reply: "There was a rebase recently. Delete and clone again."

Me: "Why would we rebase published work? This makes no sense."

Response: "Because sometimes it makes sense to do that."

{slamming head on desk}


Yes, I dislike git (though TortoiseGit makes it a lot more tolerable). I
don't blame guns when people get shot, or knives when people get stabbed,
or cars or alcohol when someone dies in a drunk driving accident. The fact
that git has a rebase command doesn't appeal to me, but if other people
want to "fix" their history before publishing it, fine. But once it is
published leave it the hell alone!


I should not have to issue:

git checkout -- .

git reset --hard HEAD

git pull


Because it was convenient for one person on a team of dozens of people to
rewrite history, thus inconveniencing the many for the sake of the one.


I know you have number choices of rants to read online. I and the entire
Scott Robison team would like to thank you for choosing us over the
competition.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Workaround for the missing 'squash' command?

[Scott Robison]

On Wed, May 11, 2016 at 4:24 PM, Marko Käning <sec001+fos...@posteo.net>
wrote:

> How to achieve a git'ish squash when merging a (private) branch into trunk?
>

https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki seems to
document this use case. You merge the private branch into a public branch.
The private branch remains private, but all the work from that branch is
now in the public branch.

How is that different than an explicit squash command?


>
> Is this deliberately missing functionality following fossil's mission to
> keep all history?
>
> Well, especially in case of a _private_ branch it might make sense to have
> such a feature: assume one wants to work locally on something which won’t
> be touched by anyone else for the time being. But when the time comes to
> make it public one might not always want to push the whole history to the
> central repo.
>
> I figure the only way is to use stg like
>
> $ fossil diff -v -r 5d7b175ba0 >patch.diff
>
> followed by
>
> $ patch 
> where needed, right?!
>
> No other way, as it seems…
>
> No plans to implement a (perhaps restricted) squash command which would
> only
> work on private branches?
> :-)
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] update vs checkout

[Scott Robison]

Note that you have to merge mybranch back to trunk, otherwise all the
changes made in mybranch will live happily over there forever. Once you
updated to trunk, you abandoned all committed work from the other branch.

On Sat, Apr 30, 2016 at 11:27 PM, Scott Robison <sc...@casaderobison.com>
wrote:

> I think that's close if I understand what you want. Maybe this gets you
> the rest of the way:
>
> (start with a clean checkout)
> (work on code)
> fossil commit —branch mybranch
> begin loop as many times as needed while working on mybranch
>fossil merge trunk
>(resolve merge conflicts and test merged workspace)
>fossil commit
>(pass code review) if needed
> end loop
> now you're ready to merge to trunk, so
> fossil update trunk
> MISSING STEP: fossil merge mybranch
> (resolve merge conflicts and test merged workspace because it is possible
> someone slipped another commit in after code review was passed)
> fossil commit
>
> On Sat, Apr 30, 2016 at 11:23 PM, Steve Schow <st...@bstage.com> wrote:
>
>>
>> On Apr 30, 2016, at 10:56 PM, Barry Arthur <barry.art...@gmail.com>
>> wrote:
>>
>> The distributed/shared repository doesn't just hold trunk... it holds all
>> non-private branches too. So when your developers are ready for you to
>> review their work, they commit it to their task branch and then you
>> (remotely) checkout/update to that branch (preferably into a fresh
>> directory) and test/inspect their code. When you're happy with it, they (or
>> you) can then merge their branch into trunk.
>>
>>
>>
>> Sorry I didn’t read this carefully the first time.  Yes that is what i’m
>> suggesting, I want to use the feature branch for both isolated development
>> as well as code review prior to committing to the trunk.  Just trying to
>> iron out exactly the sequencing of merge and update I need to do to create
>> a smooth workflow for this.  I think I have it resolved now that I
>> understand better the relationship and difference between update, merge and
>> checkout…my original question.
>>
>> The work flow would be this:
>>
>>
>> (start with a clean checkout)
>> (work on code)
>> fossil commit —branch mybranch
>> fossil merge trunk
>> (resolve merge conflicts and test merged workspace)
>> fossil commit
>> (pass code review)
>> fossil update trunk
>> fossil commit
>>
>> Here is a DOT diagram if you’re interesting.
>>
>> digraph *featurebranch* {
>> rankdir="LR";
>>node [shape=*box*];
>>*trunk*->*DeveloperA*[color=*red*];
>>*DeveloperA*->*A2*[weight=*5*,color=*red*];
>>*trunk*->*2*[style=*dotted*,weight=*8*];
>>*A2*->*merge*[weight=*8*,color=*red*];
>>*2*->*merge*[style=*dotted*,color=*red*];
>>*merge*->*3*[color=*red*];
>>*2*->*3*[weight=*8*];
>>
>>*trunk*->*developerB*[style=*dotted*,color=*blue*];
>>*developerB*->*2*[style=*dotted*,color=*blue*];
>> }
>>
>>
>>
>>
>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>
>
> --
> Scott Robison
>
>


-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] update vs checkout

[Scott Robison]

I think that's close if I understand what you want. Maybe this gets you the
rest of the way:

(start with a clean checkout)
(work on code)
fossil commit —branch mybranch
begin loop as many times as needed while working on mybranch
   fossil merge trunk
   (resolve merge conflicts and test merged workspace)
   fossil commit
   (pass code review) if needed
end loop
now you're ready to merge to trunk, so
fossil update trunk
MISSING STEP: fossil merge mybranch
(resolve merge conflicts and test merged workspace because it is possible
someone slipped another commit in after code review was passed)
fossil commit

On Sat, Apr 30, 2016 at 11:23 PM, Steve Schow <st...@bstage.com> wrote:

>
> On Apr 30, 2016, at 10:56 PM, Barry Arthur <barry.art...@gmail.com> wrote:
>
> The distributed/shared repository doesn't just hold trunk... it holds all
> non-private branches too. So when your developers are ready for you to
> review their work, they commit it to their task branch and then you
> (remotely) checkout/update to that branch (preferably into a fresh
> directory) and test/inspect their code. When you're happy with it, they (or
> you) can then merge their branch into trunk.
>
>
>
> Sorry I didn’t read this carefully the first time.  Yes that is what i’m
> suggesting, I want to use the feature branch for both isolated development
> as well as code review prior to committing to the trunk.  Just trying to
> iron out exactly the sequencing of merge and update I need to do to create
> a smooth workflow for this.  I think I have it resolved now that I
> understand better the relationship and difference between update, merge and
> checkout…my original question.
>
> The work flow would be this:
>
>
> (start with a clean checkout)
> (work on code)
> fossil commit —branch mybranch
> fossil merge trunk
> (resolve merge conflicts and test merged workspace)
> fossil commit
> (pass code review)
> fossil update trunk
> fossil commit
>
> Here is a DOT diagram if you’re interesting.
>
> digraph *featurebranch* {
> rankdir="LR";
>node [shape=*box*];
>*trunk*->*DeveloperA*[color=*red*];
>*DeveloperA*->*A2*[weight=*5*,color=*red*];
>*trunk*->*2*[style=*dotted*,weight=*8*];
>*A2*->*merge*[weight=*8*,color=*red*];
>*2*->*merge*[style=*dotted*,color=*red*];
>*merge*->*3*[color=*red*];
>*2*->*3*[weight=*8*];
>
>*trunk*->*developerB*[style=*dotted*,color=*blue*];
>*developerB*->*2*[style=*dotted*,color=*blue*];
> }
>
>
>
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] update vs checkout

[Scott Robison]

>
> its not clear to me how I can create a merged branch somewhere that has
> all of the tentative changes….in the repo…that can be reviewed
> remotely….before commiting to the trunk.  Sounds to me like its not
> possible currently with fossil.
>
> What exactly is the difference between merge and update?
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] update vs checkout

[Scott Robison]

On Sat, Apr 30, 2016 at 6:47 PM, Steve Schow <st...@bstage.com> wrote:

> Merge conflicts are possible ANY time someone else edits a file and
> commits it to the trunk while you have been working on a feature branch
> rather then the trunk for a while.  Lots of times, the software can merge
> without conflicts, but sometimes no.  And me personally I actually prefer
> to visually inspect all merges, and manually approve them, but that’s just
> me and my OCD.
>
> My workflow list may not be correct as I sit here thinking about it….and
> one thing may have just become clear to me, please correct me if I’m wrong:
>
> merge merges a version into the checkout DB, without effecting the repo.
>
> update merges changes into a branch within the repo (and also the checkout
> db).
>
> yes?
>

No. If you are on mybranch and you have uncommitted changes, and you run
update trunk, your changes will not be committed to mybranch (effectively
they will be reverted) and then they will be automatically applied to your
working copy of trunk you just updated to.

If you don't have any uncommitted changes, that can't happen.


>
> My two major goals here are this:
>
> 1 - I want devs to be able to work on a feature and commit their changes
> to their repo without hitting the trunk right away.  thus the feature
> branch.  no problem there.
>
> 2 - I want to code review exactly what they are going to commit to the
> trunk right before they do it.  The problem I see is that “merge" merges
> into their checkout, not their repo, so there is no way to remotely code
> review the final thing they are about to commit to the repo trunk.  what
> needs to happen is that I need to have the trunk merged into their feature
> branch so that the final merged result will already be in the repo to be
> reviewed remotely.
>
> So as I think about it…I don’t want to use merge..  perhaps this is a
> matter of using the leaf of trunk to merge into their feature branch…if
> that’s even possible.  Then their feature branch will be the whole merged
> enchilada that can be code reviewed remotely.  Once approved, they have to
> quickly use merge to merge the branch into their workspace, do a quick test
> and then finally commit to repo trunk.
>
> so
>
> > fossil checkout trunk
> > (work on code)
> > fossil commit —branch mybranch
> > (work on more code)
> > fossil commit
> > fossil update -n (i want to have the branch look like the trunk leaf
> is merged into it, if that’s possible)
> > (resolve merge conflicts when they rarely occur ;-)
> > fossil update
> (code review my branch)
>switch context back to trunk for their checkout, not sure exact command
> to use yet)
>   fossil merge mybranch
> > (final feature test)
> > fossil commit
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] update vs checkout

[Scott Robison]

Make that "fossil status or changes or extras or some combination thereof".
On Apr 30, 2016 6:32 PM, "Scott Robison" <sc...@casaderobison.com> wrote:

>
> On Apr 30, 2016 6:00 PM, "Steve Schow" <st...@bstage.com> wrote:
> >
> > I forgot one step in this process I want:
> >
> >
> > On Apr 30, 2016, at 5:56 PM, Steve Schow <st...@bstage.com> wrote:
> >
> > >
> > >
> > > fossil checkout trunk
> > > (work on code)
> > > fossil commit —branch mybranch
> > > (work on more code)
> > > fossil commit
> > > (code review)
>
> At this point, you've presumably committed all changes in your working
> copy to the branch. If that is correct...
>
> > > fossil update trunk -n
> > > (resolve merge conflicts when they rarely occur ;-)
>
> ... There can be no merge conflicts here. You can only have merge
> conflicts if you have uncommitted changes as I understand things. If all is
> committed, all is well.
>
> What you want is really to make sure all in progress branch changes have
> been committed or reverted before allowing update to trunk. fossil status
> or changes seem more suited than update trunk -n
>
> > > fossil update trunk
> >fossil merge mybranch
> >(resolve conflicts if needed)
> > > (final feature test)
> > > fossil commit
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] update vs checkout

[Scott Robison]

On Apr 30, 2016 6:00 PM, "Steve Schow"  wrote:
>
> I forgot one step in this process I want:
>
>
> On Apr 30, 2016, at 5:56 PM, Steve Schow  wrote:
>
> >
> >
> > fossil checkout trunk
> > (work on code)
> > fossil commit —branch mybranch
> > (work on more code)
> > fossil commit
> > (code review)

At this point, you've presumably committed all changes in your working copy
to the branch. If that is correct...

> > fossil update trunk -n
> > (resolve merge conflicts when they rarely occur ;-)

... There can be no merge conflicts here. You can only have merge conflicts
if you have uncommitted changes as I understand things. If all is
committed, all is well.

What you want is really to make sure all in progress branch changes have
been committed or reverted before allowing update to trunk. fossil status
or changes seem more suited than update trunk -n

> > fossil update trunk
>fossil merge mybranch
>(resolve conflicts if needed)
> > (final feature test)
> > fossil commit
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Colored output on console

[Scott Robison]

On Apr 25, 2016 8:48 AM, "Michael Richter"  wrote:
>
> I know that every time I mention this I get silently, perhaps even
hostilely, ignored, but really guys, why not just use fsl for your
customization needs?

I don't use fsl myself, though I have no quarrel with its existence. I
think inferring hostility in failure to mention or discuss any third party
tool on a list dedicated to the primary tool itself is a bit over the top.

Given the nature of fossil, perhaps this is an opportunity to craft a page
that could reside in in main documentation pointing people to the tool and
explaining the advantages? I can't say myself that it would be accepted,
but it seems it might have a chance. You can't expect everyone to know or
promote something they don't use.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Colored output on console

[Scott Robison]

On Apr 24, 2016 4:07 AM, "Marko Käning"  wrote:
>
> Hi devs,
>
> it would be great if one could colorise Fossil’s output on the console!
>
> Quite a few times I missed an error or warning message which slipped in
between of many lines of the usual fossil output on the console.
>
> Red colouring of words like “warning” or “error” would be very helpful
there.

I will just observe here that typically red text on a black background is
really hard for me to see. If someone were to add such a thing, having it
be opt in would be appreciated. Different people have different, of course.
I hate color blindness.

>
> The poor man’s solution would at least be to use capital letters and some
sort of line head along the lines of
>
> > ERROR: blaa
> > WARNING: blubb
>
> Right now I can’t send an example of such a easily slipping through
message, but I can deliver if I come across one again.
>
> Greets,
> Marko
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version control as backup. Was: Noob usage questions

[Scott Robison]

On Sat, Apr 23, 2016 at 12:26 PM, Steve Schow <st...@bstage.com> wrote:

> it sounds to me like your repos are backed up well as long as they are all
> completely sync’d with each other on a regular basis and so long as they
> are located on different HDD volumes and at least one copy offsite from one
> of the other copies.  Your versioning history is very well backed up for
> sure due to the distribution.
>
> However
>
> Its not clear from your description whether the workspaces of your devs
> are backed up.
>
> Also your backup may or may not cover certain odd cases.  For example,
> what if some piece of data inside the Sqlite db file is changed, something
> that is not under version control per say, its just some SQL data being
> used..config data or whatever…  And then 3 days later you realize someone
> changed that data…  if that data was sync’d between all repos during those
> 3 days, then the original is gone now, no way to get it back unless you
> have an actual backup of your DB file that was done totally outside of
> Fossil’s internal versioning and syncing capabilities.
>
> In practical terms, you’re covered very well I’d say.
>

You're strictly correct about backing up of work spaces and such. But the
same things can be said of backups (someone can mess with them). You can
never be 100% secure. Something catastrophic can happen to all backups
simultaneously. I work for a company that does automatic block level
incremental backups. I think the default interval is 15 minutes between
incrementals. Even then, it is possible for someone to create a file with
Very Important Information(TM), accidentally delete it, all within the 15
minute window.

Of course, there is also the issue of "how long do you keep backups" or
"how many backups do you keep"?

Fossil has validation code built in to help ensure that data is never lost.
It would be very difficult for anyone to gain physical / direct access to
the master repositories to change or delete existing information that has
already been recorded (it's part of the fossil record, after all). People
who have push access to a repo could theoretically craft garbage that could
be injected into a repository, I guess, but then that garbage could be
removed later when found.

Nothing is perfect, but distributed fossil to trusted locations (the three
remote plus at least one local under DRH control, for example) is pretty
good.

My favorite way of backing up data for maximum redundancy is to deduplicate
/ compress / encrypt my data, then use steganography to embed it in viral
memes and video online. Then I just have to search Facebook, Twitter, or
YouTube for my data in a disaster recovery situation. I haven't had to
recovery any data yet, but I'm certain it will be a cinch. ;)

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Noob usage questions

[Scott Robison]

On Sat, Apr 23, 2016 at 12:06 AM, Steve Schow <st...@bstage.com> wrote:

>
> On Apr 22, 2016, at 11:34 PM, Ron W <ronw.m...@gmail.com> wrote:
>
> My team's wrapper for Fossil does the following (from memory, so might not
> be exactly right):
>
> On "branch new":
>fossil commit --allow-empty --branch $bname -m "$comment (Issue
> [$issue])"
>fossil tag add --propagate issue $bname $issue
>
> On "commit":
>$issue=`fossil tag ls $revision|perl -n -e 'if /issue=(\w+)/ { print
> $1; }`
>fossil commit -m "$comment (Issue [$issue])" $args
>
>
>
> I have been perusing all the docs all evening, I can’t actually see any
> way to tell fossil which branch to commit to, so there must be some
> implicit behavior here that I am overlooking.  I can see that “checkout” is
> the command that checks out a workspace to a given VERSION, which exists on
> either the trunk or some branch.
>
> When you do the
>
> commit —branch
>
> does that change the workspace implicitly to be checked out to that branch
> instead of the trunk?  Does the workspace then become tied implicitly to
> the branch unless specifically checked out back to the trunk or another
> branch?
>

Yes.


> and thus a subsequent commit would be to the end of that branch rather
> then the trunk?  Am I right to conclude that at this point if the dev
> issues a checkout command again against a VERSION on the trunk, then
> subsequent commits would go to the end of the trunk rather then the branch?
>
> Do I have that about right?
>
> if so, not a big deal then, just have to use wrapper scripts to make sure
> to follow your work flow, always create a new branch on the first commit
> for any ticket.  I will probably use a cookie or something to make sure
> while working on a ticket, all commits go to that branch, and tag the
> commit with the [nn] number as well.
>
>  If they need to work on more than one ticket concurrently, then no big
> deal, create another branch and switch to that one for a while.
>

An even better idea (I think): Have two workspaces. One ticket lives on the
branch in the first workspace, the other ticket lives on the branch in the
second workspace. This assumes you never get confused about where you are,
but I don't think the question "which workspace am I in" vs "what is the
current branch" is any more difficult. And it saves the whole "I have to
stash my current state so I can switch branches and do some work then
switch back and unstash and so on".
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Scott Robison]

On Thu, Apr 7, 2016 at 4:45 AM, Scott Robison <sc...@casaderobison.com>
wrote:

> What is the branch tag reported by fossil status? Perhaps the branch you
> were on got renamed?
>
> On Thu, Apr 7, 2016 at 2:43 AM, John Regehr <reg...@cs.utah.edu> wrote:
>
>> Hi Andy,
>>
>> I'm returning to this topic because I again have a repo that got "stuck".
>>
>> Please see the interaction with fossil below.  I ran "fossil update
>> --latest" and it received 53 artifacts, but didn't end up updating and of
>> my local files.  And in fact, a diff between a fresh checkout of sqlite and
>> the repo below shows that I don't have the latest changes. My experience is
>> that a repo that gets stuck in this fashion will continue to receive
>> artifacts from the server but will never again update my local files with
>> fresh content.
>>
>
Sorry for the premature / top posted reply previously.

Anyway, if you are not on trunk, fossil update --latest will only take you
to the latest commit on whatever branch you are on. If a branch was
renamed, you'll be some place other than where you expected.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil update --latest not working

[Scott Robison]

What is the branch tag reported by fossil status? Perhaps the branch you
were on got renamed?

On Thu, Apr 7, 2016 at 2:43 AM, John Regehr <reg...@cs.utah.edu> wrote:

> Hi Andy,
>
> I'm returning to this topic because I again have a repo that got "stuck".
>
> Please see the interaction with fossil below.  I ran "fossil update
> --latest" and it received 53 artifacts, but didn't end up updating and of
> my local files.  And in fact, a diff between a fresh checkout of sqlite and
> the repo below shows that I don't have the latest changes. My experience is
> that a repo that gets stuck in this fashion will continue to receive
> artifacts from the server but will never again update my local files with
> fresh content.
>
> Thanks,
>
> John
>
>
>
> john@TrustInSoft-Box-V:~$ cd sqlite/
> john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest
> Autosync:  http://www.sqlite.org/cgi/src
> Round-trips: 3   Artifacts sent: 0  received: 53
> Pull done, sent: 2148  received: 33277  ip: 67.18.92.124
>
> ---
> checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 00:44:01
> UTC
> tags: pager-get-noinit
> comment:  Avoid unnecessary memset() operations in sqlite3PagerGet().
> (user: drh)
> changes:  None. Already up-to-date
> john@TrustInSoft-Box-V:~/sqlite$
> john@TrustInSoft-Box-V:~/sqlite$
> john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest
> Autosync:  http://www.sqlite.org/cgi/src
> Round-trips: 1   Artifacts sent: 0  received: 0
> Pull done, sent: 289  received: 658  ip: 67.18.92.124
>
> ---
> checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 00:44:01
> UTC
> tags: pager-get-noinit
> comment:  Avoid unnecessary memset() operations in sqlite3PagerGet().
> (user: drh)
> changes:  None. Already up-to-date
> john@TrustInSoft-Box-V:~/sqlite$
>
>
>
>
>
> On 3/8/16 3:47 PM, Andy Bradford wrote:
>
>> Thus said John Regehr on Tue, 08 Mar 2016 10:18:15 +0100:
>>
>> This usually works, but every couple of weeks my local repository gets
>>> somehow stuck in a state where  the remote changes appear to be pulled
>>> from the  server, but then they  are not applied to  my local sources.
>>> This has happened about 4 times.
>>>
>>
>> Can you be a little more specific about what this means? For example, do
>> you see the remote changes in  the timeline in your local repository and
>> Fossil simply  does not update your  open checkout to those  versions of
>> the file? Or do you not see the changes at all?
>>
>> Can you provide  some output from the commands you're  running when this
>> problem happens?
>>
>> Thanks,
>>
>> Andy
>>
>> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Scripting fossil

[Scott Robison]

On Fri, Feb 19, 2016 at 4:55 PM, Warren Young <w...@etr-usa.com> wrote:

> On Feb 18, 2016, at 7:20 PM, Scott Robison <sc...@casaderobison.com>
> wrote:
> >
> > As it turns out, this wasn't a great plan.
>
> I agree.  I even dislike checking configure scripts generated by autoconf
> and similar into repos.
>
> (Please, hold the replies.  I already know the justifications.  I just
> don’t agree.)
>
> > Since I'm using Windows, I was inclined to just use a batch file
>
> *wince*
>
> I wonder if it would be cleaner in Stephan Beal’s f-s2sh language?
>

It would have been cleaner in just about anything. But there was a
principle involved, namely bending Windows to my will.

Note: I have cygwin installed on my machine, so it's not like I couldn't
have used another more posixy tool. But this worked adequately for me.


> > fossil update next
>
> That’s worth reading this post all by itself.  I knew about most of the
> other special tags, but not that one.  Thanks!
>
> I assume “next” ignores branches, so that rewriting the repo by stepping
> through it with “next” in a loop will prune all the branches?
>

I would assume so, but don't know as I had no branches in this repo and no
repo with branches from which I wanted to excise any history.

This was a pretty special case. :)
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Scripting fossil

[Scott Robison]

Here is a post describing a process I used to "change history" in a repo.
Perhaps it might be useful to someone at some point.

Two years ago I started using fossil to track my personal website / blog.
My plan at the time was to use a static site generator and to keep the
generated content under version control as well, to simplify the process of
pushing to my actual website after editing and building the blog.

As it turns out, this wasn't a great plan. As a result, I had a 200 MB
repository holding tons of build artifacts that I really didn't need to
keep around. So I decided to rebuild my repository, removing the cruft that
can be rebuilt on demand, and just keeping the other pieces.

In git this would be "no problem" of course (other than the problem that I
was using git). I could throw away stuff willy nilly.

Since I'm using Windows, I was inclined to just use a batch file to migrate
individual commits from the old repo to a new repo, excluding the pieces I
no longer wanted to keep track of. Before I could do that, I needed to
"clean up" the existing repo a little bit. I had used some special
characters in comments that would trip up batch processing (parentheses,
quotation marks, ampersands, percent signs, vertical bars and less than /
greater than symbols; anything else that would cause cmd.exe to choke), so
I edited the offending commit comments in the old repository. Maybe a dozen
or so in my case.

Next I opened a copy of old repository at the initial empty commit.

Then I created a new empty repository using the --date-override, --template
and --admin-user options to initialize the desired state.

I wrote the following batch file named donext.bat that would do the
annoying repetitive work:

**

@echo off

pushd D:\path\to\old\checkout
fossil update next
fossil status > D:\path\to\temp.txt
popd

rem modify the /xf and /xd parameters as needed to exclude the parts you
don't want in the new repository
robocopy D:\path\to\old\checkout D:\path\to\new\checkout *.* /mir /xf
_FOSSIL_ /xf *.pyc /xd public

for /f "delims=" %%L in (D:\path\to\temp.txt) do call :getvar "%%L"

pushd D:\path\to\new\checkout
fossil addremove
fossil commit --date-override %dndatetime: =T% -m "%dncomment%"
rem the following isn't strictly necessary, but it gave me some idea where
I was in the process
fossil timeline
popd

goto :EOF

:getvar
set dnline=%~1
if "%dnline:~0,9%"=="checkout:" set dndatetime=%dnline:~55,-4%
if "%dnline:~0,8%"=="comment:" set dncomment=%dnline:~14,-14%
goto :EOF

**

My old repository had 107 commits after the initial empty commit. So I ran
one final command line:

for /L %L in (1,1,107) do donext.bat

Which ran my donext.bat file 107 times, migrating all the commits to the
new repository without the generated artifacts.

I don't see this being something I'm likely to need again, but I wanted to
document it in case it was useful for someone else as an example of how it
might be done on a Windows platform (where "someone" might be me when I
find out I have another use for it but long since deleted the "trivial"
batch file). Certainly a lot easier than trying to do all those steps
manually 107 times.

In the end it "failed to commit" about 10 or so because there were no
differences (all the differences were in no omitted artifacts). And my
useful repository is about half the size it was before.

Note that this script is not a generic tool that will Just Work(TM) on your
repository setup. It makes assumptions likely unique to my configuration
(hard coded paths, a single user name being used for all commits, no
branches, maybe more). Still, it might be a useful reference.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compiling and running Fossil on old hardware

[Scott Robison]

On Sun, Feb 14, 2016 at 9:57 PM, Warren Young <w...@etr-usa.com> wrote:

> On Feb 13, 2016, at 10:41 PM, Scott Robison <sc...@casaderobison.com>
> wrote:
> >
> > I wonder if I could build fossil for my old Commodore 64.
>
> No way.  Contemporary compilers would have been pre-ANSI, so they wouldn’t
> even understand the function signatures, for a start.
>

Of course. I was just joking, to be clear, hence why I went with the disk
swapping idea.


> > It would certainly require a lot of disk swapping. Not virtual memory
> paging, literal "Please insert Disk 43" type disk swapping. :)
>
> I used a C compiler called Aztec C briefly on an Apple //e:
>
>   http://www.aztecmuseum.ca/
>
> Perhaps you’ve heard of it; they had C64 and C128 versions.
>

I never used it on a Commodore, but did use it in my first professional
programming position in the late 80s on PCs.


> We’ve come a long way.  I suspect the oldest thing you could get Fossil
> running on without massive code changes are Unix workstations from around
> 1990, like the early SPARCstations.
>

Yeah, I don't feel like building an emulation of a virtual memory system
and my own tool chain to chase it.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] opening more than one ui on localhost

[Scott Robison]

On Sun, Feb 14, 2016 at 5:33 PM, Andy Bradford <amb-fos...@bradfords.org>
wrote:

> Thus said Scott Robison on Sun, 14 Feb 2016 05:10:49 -0700:
>
> > There is a lot of intelligence that goes into mailing lists that might
> > not be captured in the repository without extra effort.
>
> I don't think it would be much effort to subscribe an email address to a
> mailing list that has a filter which take all email that it receives and
> adds it as an artifact into a project.
>
> $ cat ~/.qmail-project-bot
> | bin/incorporate project
>

In this case the extra effort is relatively modest and automates what would
otherwise be a tedious manual process. :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] opening more than one ui on localhost

[Scott Robison]

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" viewing option in email-list-style
>> discussions, I realized that Wikipedia has had a solution that could be
>> easily implemented in Fossil projects without any software tweaking -
>> just create User:talk or Subject:talk pages, like Wikipedia has been
doing.
>
>
> after following this thread loosely these last 1-2 days, just a short
comment: you are proposing a "solution" for exactly which "problem"? I
don't see any and would support the conservative approach here, i.e. "if it
ain't broken, don't fix it": email does the job just fine for the purpose
of this list in my view. I don't see _any_ problem, let alone one, that
switching to some sort of forum would fix (quite to the contrary, partly).
I believe the arguments have been all mentioned already, mainly by warren
young. so what exactly are your remaining gripes with just continuing to
use the present channel of communication (except that it seems somehow
(technically or otherwise) uncool to you ;-)) for discussions regarding
fossil (which is the only purpose of this list...)?


I was under the impression that it was more of a suggestion of something
the OP would like to use and less advocating for the fossil project to
embrace it.

That being said, I can see certain benefits to keeping "all" that
information around in the project repository itself. From the fossil design
objectives:

> Fossil should provide in-depth historical and status information about
the project through a web interface
> {snip} Fossil attempts to better capture "collective intelligence" and
"the wisdom of crowds" {snip}

Also:

> The global state of a fossil repository is kept simple so that it can
endure in useful form for decades or centuries. A fossil repository is
intended to be readable, searchable, and extensible by people not yet born.

There is a lot of intelligence that goes into mailing lists that might not
be captured in the repository without extra effort.

Note that I'm not advocating for change, but part of me likes the idea.
More realistically there can be a lot of noise in forums and mailing lists
and such that you wouldn't necessarily want to keep in the fossil record,
much more so than changes to code or documentation.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Compiling and running Fossil on old hardware

[Scott Robison]

I wonder if I could build fossil for my old Commodore 64. It would
certainly require a lot of disk swapping. Not virtual memory paging,
literal "Please insert Disk 43" type disk swapping. :)

On Sat, Feb 13, 2016 at 9:34 PM, Andy Bradford <amb-fos...@bradfords.org>
wrote:

> Thus said Stephan Beal on Sat, 13 Feb 2016 20:25:19 +0100:
>
> > If you're that hard-up for a machine,  i've got a Raspberry Pi you can
> > have ;).
>
> Haha, it isn't  my primary machine, just one that  I enjoy tinkering on,
> but thanks for the offer.
>
> Andy
> --
> TAI64 timestamp: 400056c003e8
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] is fossil repo web configuration possible from command-line?

[Scott Robison]

On Wed, Jan 20, 2016 at 8:33 PM, dewey.hyl...@gmail.com <
dewey.hyl...@gmail.com> wrote:

> i'm a command-line junkie, and tend to script/automate everything ... and
> i tend to create a lot of fossil repos for small projects. so i'm trying to
> figure out how to programmatically configure individual repos so that i
> don't have to deal with the web browser for configuration.
>
> i'm currently able to create users and set permissions and such, but so
> far i haven't been able to figure out how to set:
>
> project name
> project description
> index page
>
> how can this be done via command-line? and where is this documented? i'm
> sure i'll end up wanting more configuration items, but figure if someone
> can explain this part to me i'll be able to figure out the others.
>

I created my own PHP based front end to a multi-repo fossil setup that
allows me to create a repo using any of the others as a "template" and
specify the project name & description. It uses SQL to tweak the settings
rather than anything specific to fossil. I'm happy to share what I have
(ugly though it is) if you think it might be helpful.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Scott Robison]

Is a sql database fault tolerant? I guess so, but think that is not what
most people consider fault tolerant.
On Dec 16, 2015 9:36 AM, "Stephan Beal"  wrote:

> Section 4.1: in fossil, but not git: fault-tolerant storage.
>
> - stephan beal, sgb...@googlemail.com
> Written on a keyboard attached to a telephone attached to a TV screen, via
> an app written for use on touchscreens. Please excuse brevity, typos, and
> whatnot.
> On Dec 16, 2015 5:16 PM, "Richard Hipp"  wrote:
>
>> Based on comments on HN and on this mailing list, I have attempted to
>> rewrite the fossil-v-git.wiki document
>> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
>> better summarize the differences between the two products.
>>
>> Your feedback on the rewrite, and especially suggestions for improving
>> it, are welcomed.
>>
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 4:06 AM, Stephan Beal <sgb...@googlemail.com> wrote:

> On Wed, Dec 16, 2015 at 11:59 AM, Gaurav M. Bhandarkar <
> gaurav.a...@gmail.com> wrote:
>
>> "git rebase -i" seems to enable me to work on multiple projects at the
>> same time. Because of it I can maintain versioned "development sessions" of
>> not only my code but other things that were required/relevant to make that
>> code. Without it I find it impossible to handle the "context switch" that
>> comes when you work on multiple projects.
>>
>
> fossil supports multiple open checkouts of any given repo db copy, which
> is arguably a cleaner approach than temporarily sticking stuff into SCM
> (when you've no intention of keeping it there). It's a matter of taste, of
> course, but fossil does offer an option other than keeping separate trains
> of thought in the same physical copy of the tree. To me that seems simpler
> than [ab]using the SCM for that type of thing, in particular because a
> context switch is a simple 'cd' instead of SCM commands.
>

I realize that 'get rebase -i' gives a lot more tools, but couldn't 99% of
rebase use cases be handled with private branches? I've never used private
branches until today (just for testing purposes), and from what I see I can
do whatever I want in the private branch, merge from trunk, cherry pick,
reverse out, whatever to make the tip of my private branch 100% pristine
and proper, and only then merge it to trunk. I could just as easily have
created a new branch off the tip of trunk,and merged my private branch to
the public branch, which I could then merge to trunk so that people aren't
upset at me for working on trunk.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 4:12 PM,  wrote:
>
> Hmm.. If one can create a private branch, do all draft work there and
when done merge to trunk (or other non-private branch), then sync with the
main repo, the main repo will not contain any traces of the private branch
(with the draft work).  Am I correct?

That seems to be the case based on my limited testing earlier today.

> So, if then the local repo is deleted and a new one created by cloning
the main repo, we end up with the desired effect: a repo that does not
include any ‘bloat’ from the private work.

That sounds correct.

> But, since many people (myself including) seem to like the idea of draft
work that once merged into mainstream branches should no longer take up
space (forever) in the repo, and given that the above procedure actually
achieves this goal, wouldn’t be nicer to have an explicit command (or
option to existing command) to purge a private branch at the local level?


>From http://fossil-scm.org/xfer/doc/trunk/www/private.wiki:

> You can remove all private branches from a repository using this command:
> fossil scrub --private
> Note that the above is a permanent and irreversible change. You will be
asked to confirm before continuing. Once the private branches are removed,
they cannot be retrieved (unless you have synced them to another
repository.) So be careful with the command.

I just tried it and it worked. Also included is a warning that it is all or
nothing. You can scrub all private or no private, but not one or some
private (unless one or some are equal to all). :)

SDR
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 4:53 PM, Warren Young <w...@etr-usa.com> wrote:

> On Dec 16, 2015, at 2:28 PM, Scott Robison <sc...@casaderobison.com>
> wrote:
> >
> > couldn't 99% of rebase use cases be handled with private branches?
>
> Probably not with the current design.  For one thing, there are no
> “branches”, only “branch.”  That is, the private branch is always called
> “private”, so that when you commit to it, return to trunk, and create a new
> private branch, you’re actually forking the original private branch.
>

I have a test repo at present with three private branches named test, bob,
and sue.


> In order to have Git-like private branches, I think the design would have
> to change to allow multiple independent private branches.
>
> Not that I’m asking for such a thing.  I already made public my opinions
> about working in private.  (“Guy in the room” syndrome.)
>
> > I can do whatever I want in the private branch, merge from trunk, cherry
> pick, reverse out, whatever to make the tip of my private branch 100%
> pristine and proper, and only then merge it to trunk.
>
> That’s pretty much the definition of “guy in the room.”  Why are we
> re-learning this lesson 44 years after its dangers were first published?
>

I'm not advocating working that way. I'm just allowing that fossil could
work for people who want to work that way in some / most cases.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 6:41 PM, Ron W <ronw.m...@gmail.com> wrote:

> On Wed, Dec 16, 2015 at 6:53 PM, Scott Robison <sc...@casaderobison.com>
> wrote:
>
>> > You can remove all private branches from a repository using this
>> command:
>> > fossil scrub --private
>> > Note that the above is a permanent and irreversible change. You will be
>> asked to confirm before continuing. Once the private branches are removed,
>> they cannot be retrieved (unless you have synced them to another
>> repository.) So be careful with the command.
>>
>
> But scrub doesn't accept names to specify which branches to purge. (Just
> pointing that out. I've not yet had a reason to purge any branches.)
>

Right. I think I said that. If not, I said corrected.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Scott Robison]

On Wed, Dec 16, 2015 at 10:34 PM, Gaurav M. Bhandarkar <
gaurav.a...@gmail.com> wrote:

> > Don't need rebase to use fast-forward merge.
>
> Normal merge or rebase both "enables" fast-forward merges. But the
> advantage "rebase-before-ff-merge" has is that it avoids other(s) extra
> "merge commits" that you would have done to get your branch updated with
> changes from remote.
>
> See the section "Don't merge upstream code at random points":
> https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
>
>
> > You can use private branches to the same effect
> I'm not sure. The thing that immediately comes to mind is that fossil's
> private branches will show up as a single commit in the public branch.
>

It depends on how you go about it:

Create a private branch off trunk. Edit, commit, do whatever you want with
it.

When you're finished and ready to rebase, create a public branch off trunk
and cherry pick merge the private commits you want in the public history.
You have as much opportunity as you want to clean and massage them.

Now you can merge that branch to trunk.

I'm not trying to suggest it is in any way nearly as "elegant" as "rebase
-i" (those who prefer that would find this clunky at best). Still, it seems
possible.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil mentioned on HN

[Scott Robison]

On Tue, Dec 15, 2015 at 9:20 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 12/15/15, Warren Young <w...@etr-usa.com> wrote:
> > On Dec 15, 2015, at 5:54 AM, Richard Hipp <d...@sqlite.org> wrote:
> >>
> >> https://news.ycombinator.com/item?id=10737131
> >
> > Could someone who understands “git rebase” weigh in on that thread?
> People
> > are claiming that “fossil shun” means there is no difference between Git
> and
> > Fossil.
> >
> > Either my understanding of fossil shun is just as weak as my
> understanding
> > of git rebase, or this is a false equivalency, and we can’t have [people
> > getting away with being wrong on the Internet][1]. :)
> >
>
> Shun does *not* provide the equivalent of rebase.  Claims that it does
> are misinformed.
>
> I think people are making a bigger deal out of this than it deserves.
> The main different between Fossil and Git with regard to rebasing is
> summarized well in the docs:
>
>   "Git remembers what you should have done whereas Fossil remembers
> what you actuallydid."


Having been forced to use git more and more often of late at work (I held
onto the legacy svn repo as long as possible) I think we get a little
caught up in rebase when we really don't need to. Yes, rebase can be (and
is) abused. I think a rebase-like command could be implemented in fossil
(based on previous of many discussions) that preserved the history (moved
to a different branch, marked appropriately) yet gave the benefits people
are looking for, and that would not necessarily be a "bad thing".

If we want to talk about how git is inferior because it supports first
class deletion of history, we need look no further than branch deletion. "
http://stackoverflow.com/questions/14005854/what-to-do-with-branch-after-merge
"

git supports, and appears to encourage, a workflow where you create a
branch, do the work, merge to master/trunk/whatever, then delete the
branch. So:

1. Create a branch.
2. Commit to the branch regularly.
3. Get ready to merge by rebasing your branch.
4a. Merge your branch to trunk and only push trunk.
4b. Push your branch and merge it.
5. Delete branch.

This workflow makes me long for the days where all I had to worry about was
a usually simple rebase operation.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil repo on a network share?

[Scott Robison]

On Nov 18, 2015 1:28 AM, "Stephan Beal"  wrote:
>
> On Wed, Nov 18, 2015 at 9:19 AM, Dömötör Gulyás 
wrote:
>>
>> And unfortunately not all devs sit in the same building. Anyway, I'll
just upload a repo, probably most people will just read it, and when
changes are to be made, it'll be on me to manage merging anyway. This
really isn't a software company :/
>
>
> You have been warned.
>
> Why not host the repo on an external site via CGI? A hoster capable of
this costs $5/month, and anyone with internet access will be able to reach
it (provided they know where it is).

And if one is concerned about the price of such a hoster, or the potential
security ramifications of keeping repos on a server you don't own or
control, it can be pretty easy to setup a VM on a home computer if you have
anything remotely close to a static IP.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil internal error: out of memory

[Scott Robison]

On Mon, Nov 16, 2015 at 8:12 AM, Andy Bradford <amb-fos...@bradfords.org>
wrote:

> Thus said Alexey Pechnikov on Mon, 16 Nov 2015 13:16:32 +0300:
>
> > Hmm, It's  only 1Gb  total size  of my files.  I have  8GB RAM  on the
> > laptop and 16GB RAM on the server. But  it's not enough as I see. So I
> > sure it's bug. Do you understand the issue now?
>
> Have you ruled out the possibility  that your OS is restricting fossil's
> access to memory?
>

Most notably: Are you sure you are using a 64-bit executable on a 64-bit
OS? Most 64-bit OSes support 32-bit executables. If that is true in your
case, the amount of memory available on your system is (usually mostly)
irrelevant. A 32-bit executable can only address 4 GiB of memory, and some
of that is going to be consumed by the OS and won't all be available for
you.

Windows, for example, defaults to a 2 GiB split historically, so the
maximum you'll ever be able to allocate is 2 GiB (and the OS will hold onto
2 GiB). There is a way to compile Windows apps to see a 3 GiB / 1 GiB
split, but you have to go out of your way to do it and most applications do
not.


>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 40005649f289
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil repo on a network share?

[Scott Robison]

It is theoretically doable, but ill advised, given that the underlying
SQLite database depends on an accurate / dependable file system, and
network file systems are notoriously 'fragile' from the point of view of
data integrity.

On Mon, Nov 16, 2015 at 3:57 PM, Dömötör Gulyás <dognot...@gmail.com> wrote:

> I've got an environment where it'd be good to put a fossil repo onto a
> windows network share, as running an actual server is hindered by corporate
> IT policy. Has anybody done this, or is this at least theoretically doable?
>
> Cheers & thanks,
> DG
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Unexpected merge conflict

[Scott Robison]

On Sat, Nov 14, 2015 at 2:38 PM, <to...@acm.org> wrote:

> Thanks for the detailed explanation.  It makes perfect sense now.
>   Certainly, a rather difficult task to get right algorithmically.
>

I know. It is amazing to me that three way merge works as often as it does.
:)


>
> Many thanks also to all previous respondents.
>
> *From:* Scott Robison <sc...@casaderobison.com>
> *Sent:* Saturday, November 14, 2015 8:22 PM
> *To:* Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org>
> *Subject:* Re: [fossil-users] Unexpected merge conflict
>
> Thanks for this. It made it easy for me to visualize what is going on --
> and no debugging was necessary! :)
> ...
> I hope that explanation makes sense.
>
> Perhaps it would make sense to modify the "common ancestor" line in the
> marked up merge file to call it the baseline? Or "BASELINE (often known as
> COMMON ANCESTOR)"? Or something along those lines...
>
> --
> Scott Robison
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Unexpected merge conflict

[Scott Robison]

On Fri, Nov 13, 2015 at 6:14 PM, <to...@acm.org> wrote:

> The following Windows batch file will reproduce the condition I’m talking
> about (f = fossil):
> 
> f new sample.fossil
> f o sample.fossil
> echo Hello > hello.txt
> f add hello.txt
> f com -m Initial
> echo Hello, World > hello.txt
> f com --branch other -m "Added World!"
> echo Computer said: Hello, World > hello.txt
> f com -m "Added 'Computer said'"
> f up trunk
> f me other --cherrypick
>

Thanks for this. It made it easy for me to visualize what is going on --
and no debugging was necessary! :)

While the marked up hello.txt (with BEGIN MERGE CONFLICT / END MERGE
CONFLICT lines shown) does not directly reveal the identity of the
artifacts used to get the individual lines, the fact that this repository
only has three commits (excluding the empty initial commit that is
irrelevant) of single line files makes it easy. Additionally, when there is
a merge conflict, fossil creates filename-baseline, filename-merge, and
filename-original files that show us exactly which file is which.

The common ancestor is "Hello, World" (from the second commit, aka the
first commit on branch other). In reality this is a misnomer based on what
we would consider an ancestor, because it is not an "ancestor" of trunk.
More accurately it is called a baseline in a three way merge (as it is in
the hello.txt-baseline file).

The local copy is "Hello" from the tip of trunk.

The merged in copy is "Computer said: Hello, World" from the tip of other.

In a normal (non cherrypicked) merge, the common ancestor would be the tip
of trunk. The local copy and common ancestor would be the same.

Regardless of normal or cherrypicked merge, the simplified process is as
follows:

Compute the set of diffs from common ancestor to local copy. Call it A.
Compute the set of diffs from common ancestor to merged in copy. Call it B.
For each member b of B (consisting of a block of lines from line x to line
y):
  Is there a member a of A (consisting of a block of lines from line t to
line u) that overlaps with b?
No, merge it into the local copy.
Yes, there is a merge conflict.

Given our baseline, local, and merged in files:

A: [1-1] (line 1 'changed' from "Hello, World" to "Hello")
B: [1-1] (line 1 'changed' from "Hello, World" to "Computer said: Hello,
World")

The two blocks overlap completely with one another, so the line based three
way merge doesn't know which line to take.

The difference between the normal vs cherrypicked merge is the selection of
the baseline:

In a normal merge, you find the nearest common ancestor and use it as the
baseline.
In a cherrypick merge, you use the parent of the to be merged commit as the
baseline.

And that is why in your case, the fact that "SRF_OUT" was never referenced
in trunk was confusing. It was not in the trunk, but was in the baseline,
which was not strictly speaking a common ancestor, but the terminology used
was inaccurate / confusing for a cherrypick merge.

I hope that explanation makes sense.

Perhaps it would make sense to modify the "common ancestor" line in the
marked up merge file to call it the baseline? Or "BASELINE (often known as
COMMON ANCESTOR)"? Or something along those lines...

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Unexpected merge conflict

[Scott Robison]

On Nov 13, 2015 9:15 AM, "Tony Papadimitriou"  wrote:
>
> Sorry for the confusion.
> By “merge from trunk” I mean I’m in branch ‘trunk’ and from there I’m
doing the merge.
> And, I’m merging the “check-in from the ... [other] branch”  I mean the
check-in which is part of the other part.
>
> I think I’m beginning to understand what’s going on.  If I do a full
merge (no cherry pick) there are no conflicts.
> So, it seems the fact that the SRF_OUT label was renamed in an earlier
check-in that the one I’m cherry picking is confusing it.
> What should have happened actually (what I expected with the cherry pick)
is not exactly what I mentioned earlier.
> The ‘puts’ change being part of the check-in I cherry picked should have
merged in and the SRF_OUT rename (being from an older check-in) in the
development branch should have stayed out.
>
> This is a conflict if you look at this line of code as one piece (i.e.,
you either merge the whole line or none of it).

I believe with 99% confidence that you've hit the nail on the head. Merge
is line based. It either merges one or a block of lines as a single entity.
It doesn't deal with line fragments. To prove this to yourself, you could
create a repo with a single file and a single line of text. Branch it an
add a character to the end. Go back to trunk and create a new commit with
an new character at the beginning of the line. Try to merge. The same line
was modified in both branches so it isn't sure what to do.

I'm doing this from memory on my phone, so if I'm wrong, my apologies. And
I'll be surprised! :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users