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] Fix for stash-next pointer (fix for the fix)

[Scott Robison]

On Thu, Aug 18, 2016 at 2:06 PM, Warren Young  wrote:

> On Aug 17, 2016, at 5:21 PM, Kain Abel  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] Unversioned files.

[Scott Robison]

On Sun, Sep 11, 2016 at 1:49 PM, Adam Jensen  wrote:

> On 09/11/2016 01:54 PM, Stephan Beal wrote:
> > On Sep 11, 2016 18:18, "Adam Jensen"  > <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] Unversioned files.

[Scott Robison]

On Sun, Sep 11, 2016 at 3:27 PM, Adam Jensen  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] Files named "AUX" on Windows

[Scott Robison]

On Tue, Oct 4, 2016 at 10:22 AM, Pierpaolo Bernardi 
wrote:

> On Tue, Oct 4, 2016 at 6:15 PM, Richard Hipp  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] 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  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] 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] on sha1 as a hash

[Scott Robison]

On Wed, Oct 19, 2016 at 2:36 AM, Aldo Nicolas Bruno 
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] 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] 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] 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] Support for commonmark markdown in fossil

[Scott Robison]

On Sat, Mar 11, 2017 at 7:07 AM, Mark Janssen  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] 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] 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] [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] [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]

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] 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] 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] Couple of beginner questions

[Scott Robison]

On Thu, Mar 30, 2017 at 3:17 PM, Ross Berteig  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] 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] 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 ignore-glob

[Scott Robison]

On Mon, Apr 10, 2017 at 1:05 PM, Thomas  wrote:
> On 2017-04-10 20:00, Scott Robison wrote:
>>
>> On Apr 10, 2017 12:48 PM, "Thomas" > <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 Mon, Apr 10, 2017 at 1:58 PM, Thomas  wrote:
> On 2017-04-10 20:34, Scott Robison wrote:
>>
>> On Mon, Apr 10, 2017 at 1:05 PM, Thomas  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 2:57 PM, Thomas  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 Apr 10, 2017 5:02 PM, "Thomas"  wrote:

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

> On Mon, Apr 10, 2017 at 2:57 PM, Thomas  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 Tue, Apr 11, 2017 at 10:36 AM, Thomas  wrote:
> On 2017-04-11 05:22, Scott Robison wrote:
>>
>> Perhaps it should be documented, but I don't think it is a bug. It is
>> the software doing the job it was originally told to do (track versions
>> of a file) instead of doing the job it was 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 Tue, Apr 11, 2017 at 2:31 PM, David Mason  wrote:
>
> On 11 April 2017 at 14:34, Scott Robison  wrote:
>>
>> No, it is an explicit command clearly stating the user's desire for
>> exclusion of these files *that are not already under source control*.
>> The fact that the user does not remember or 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 3:04 PM, Thomas  wrote:
> On 2017-04-11 19:34, Scott Robison wrote:
>>
>> No, I try to explain why what you see isn't a design flaw, and
>> apparently fail. But I'll keep trying!
>
>
> Since I've never heard of any software that would not ignore files it is
> told to ignore 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 

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

[Scott Robison]

On Tue, Apr 11, 2017 at 3:11 PM, Thomas  wrote:
> On 2017-04-11 22:01, Scott Robison wrote:
>>
>> On Tue, Apr 11, 2017 at 2:31 PM, David Mason  wrote:
>>>
>>> I think --ignore should give an error if the --ignore matches a file
>>> already
>>> in the repository.  The current behaviour is clearly 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:21 PM, Thomas  wrote:
> On 2017-04-11 22:11, Thomas wrote:
>>
>> On 2017-04-11 22:01, Scott Robison wrote:
>>>
>>> I was thinking about that earlier (well, a warning, not an error,
>>> which presumes you can't continue). Then the questions I put above
>>> came into my mind 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:39 PM, Scott Robison  wrote:
> On Tue, Apr 11, 2017 at 3:21 PM, Thomas  wrote:
>> On 2017-04-11 22:11, Thomas wrote:
>>
>> add
>>--ignoreIgnore unmanaged files matching
>> patterns from the comma separated list of
>> 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 4:11 PM, Thomas  wrote:
> On 2017-04-11 22:51, Scott Robison wrote:
>>
>> On Tue, Apr 11, 2017 at 3:39 PM, Scott Robison 
>> wrote:
>>>
>>> On Tue, Apr 11, 2017 at 3:21 PM, Thomas  wrote:
>>>>
>>>> On 2017-04-11 22:11, Thomas wrote:
>>>>
>>>> add
>>>>--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 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 crlf-glob *

[Scott Robison]

On Wed, Apr 12, 2017 at 2:10 PM, Thomas  wrote:
> On 2017-04-12 18:01, Scott Robison wrote:
>>
>> On Apr 12, 2017 10:31 AM, "Thomas" > <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 Wed, Apr 12, 2017 at 4:41 PM, Thomas  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] 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] 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] 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] manifest setting "l" flag

[Scott Robison]

On Sep 29, 2017 7:43 AM, "Andy Goth"  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] 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] 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] 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] 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] 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

[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&utm_medium=email&utm_campaign=brand-loyalty&utm_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

[fossil-users] svn to fossil-scm migration

[Scott Robison]

So, I have a subversion repository that I've been using for about 18
months for personal stuff I work on at home and a parallel trac
installation. It has served me well, but I figured I should try out a
dvcs since the world is moving that way. Having been a fan of SQLite
for years I discovered fossil and liked what I read (integrated bug
tracking & wiki) and wanted to give it a shot.

I downloaded a fossil binary for Windows, created an empty repository,
played around with it for a bit, liked it well enough to take the next
step of importing my subversion repository and see how that worked.

After searching for a while, I found a way to import my svn repository
into fossil. svnadmin dump followed by svn-dump-fast-import followed
by fossil import --git. It 'worked' in that I had a fossil repository
after all was said in done. I ran fossil ui, looked at the timeline of
20 most recent items, so far so good. Next I clicked on 200 entries
and got an APPCRASH from Windows 7. "fossil.exe has stopped working"
with the typical check/close/debug options.

I fear that my problem is probably likely due to the very different
models between svn & fossil (or maybe a less than perfect conversion
utility). My svn repo resembles:

\repo
  \trunk
\projects
\vendor
  \third-party-libraries
  \vendor
\third-party-libraryies
  \tag-1
  \tag-2
  \tag-3
  \current

Is there a better way to do what I'm trying to do, or should I give up
on the 'ideal' of keeping my subversion history in the new fossil
repository? Also: is it practical to try to maintain multiple projects
in a single repository as I'm trying to do, or should I give that up
and go for a single repo per project?

Thanks for any suggestions & guidance. I really want to like fossil
but am having 'growing pains' or 'migration pains'.

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] svn to fossil-scm migration

[Scott Robison]

On Tue, Mar 15, 2011 at 2:51 PM, Richard Hipp  wrote:
>
> It should never crash, regardless of any model differences.
>
> What version of Fossil are you running?  (What does "fossil version" say?)
>
> Can you send me your repo by private email so that I can try it here and
> debug the problem?
>

One, fossil version reports "This is fossil version [1d93222627]
2011-03-01 19:04:32 UTC", downloaded from the fossil-scm.org site at
"2011-03-12 09:23:15 UTC".

Two, I would be happy to send the repository to you by private email.
Well, more like a link to a file in a private email, since the fossil
repo is about 425 MB (not MiB). If you are still interested in seeing
a copy of the repo, let me know and I'll forward the required
information.

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] svn to fossil-scm migration

[Scott Robison]

When I said "very different models" I meant "different models of usage
between a centralized vs distributed vcs". And I was right! :)

In any case, glad the repo was useful to you to in improving fossil.
Rather than trying to dump my entire centralized repo into a single
distributed repo, I'll have to try breaking it into separate projects.
Still trying to get my head around the dvcs model.

I've heard people going on and on about how great dvcs systems are,
but I just haven't been able to see it from their perspective. The
selling point to me about fossil is the integration of bug tracking &
wiki & all those other goodies that I currently have to maintain
separately. Svn & Trac are a nice cooperative pair, but I really like
the idea of a single exe along with a single repository file.

I'd better stop rambling. Thanks again for your immediate attention to
the report and the fix.

Take care.

SDR

On Tue, Mar 15, 2011 at 6:39 PM, Richard Hipp  wrote:
> On Tue, Mar 15, 2011 at 4:00 PM, Scott Robison 
> wrote:
>>
>> I fear that my problem is probably likely due to the very different
>> models between svn & fossil (or maybe a less than perfect conversion
>> utility). My svn repo resembles:
>>
>> \repo
>>  \trunk
>>    \projects
>>    \vendor
>>      \third-party-libraries
>>  \vendor
>>    \third-party-libraryies
>>      \tag-1
>>      \tag-2
>>      \tag-3
>>      \current
>>
>> Is there a better way to do what I'm trying to do, or should I give up
>> on the 'ideal' of keeping my subversion history in the new fossil
>> repository? Also: is it practical to try to maintain multiple projects
>> in a single repository as I'm trying to do, or should I give that up
>> and go for a single repo per project?
>
> Thanks for sending your repo!  It is quite interesting.  The tip of trunk
> contains 446,786 different files in 37,217 directories, including:
>
> * Complete sources to 5 different versions of Python
> * Complete sources to 15 different versions of SQLite
> * Complete sources to 8 different versions of Boost
> * Complete sources to 4 different versions of Tcl and of Tk
> * Complete sources and data files to 8 different versions of ICU
> * Plus multiple versions of 11 other vendor libraries...
>
> A complete checkout is 5.7GB.
>
> Fossil should not segfault, and I will fix that problem.  But in the
> meantime, I have these recommendations:
>
> (1) Keep vendor libraries in separate repositories - one repo per library.
>
> (2) If you really need to keep vendor libraries in your own repository, use
> the versioning system to store different versions of the vendor libraries as
> different check-ins.  Do not create separate subdirectories storing
> different versions of the same library all within the same check-in.  It's a
> versioning system, not a filesystem.
>
>
>>
>> Thanks for any suggestions & guidance. I really want to like fossil
>> but am having 'growing pains' or 'migration pains'.
>>
>> SDR
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
>
> --
> 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] Commit question

[Scott Robison]

I believe Ctrl-Z is defined as EOF in ASCII which predates Microsoft.
Terminating text files with EOF was the solution employeed by CP/M because
file sizes were a sector count instead of a byte count.
On Apr 5, 2011 3:06 PM, "Ron Wilson"  wrote:
> On Tue, Apr 5, 2011 at 3:49 PM, Remigiusz Modrzejewski
>  wrote:
>> On Apr 4, 2011, at 22:55 , Stephan Beal wrote:
>>> On a related note: some tools (like cvs or svn) warn if a file's last
line
>>> has no end-of-line marker. That's because (as i was taught, anyway) the
>>> official definition of a text file is basically variable-length records
>>> separated by a record separator (an end-of-line sequence (\n on *nix,
\r\n
>>> on Windows)), and that the last record must also have such a separator.
>>
>> Actually, this way the definition says that the last line can not have a
\n. You
>> probably wanted to write "ended by a record separator", but then the word
>> separator is misleading ;)
>
> I recall it being defined as variable length records, each ending with
> a record terminator, which was, because of the way teletype machine
> worked, CR-LF. (Though, with the real machine, LF-CR had the same end
> result.) Interestingly, Microsoft choose control-Z as end-of-file,
> rather than any of the other defined control values that might have
> been better. My guess is that that was because Z is the last letter of
> the alphabet, and Z being closest to the lower left corner of the
> keyboard.
> ___
> 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] Commit question

[Scott Robison]

Ah, thank you. I am on the road with barely enough bandwidth to email. At
least I was smart enough to give myself an out with "I believe" instead of
stating it as solid fact. :)

SDR
On Apr 5, 2011 6:48 PM, "Ross Berteig"  wrote:
> At 06:37 PM 4/5/2011, Scott Robinson wrote:
> >I believe Ctrl-Z is defined as EOF in ASCII...
>
> In ASCII, Ctrl+Z is SUB, intended to substitute for a damaged
> character read from tape or received in a channel. ASCII did not
> define a specific "end of file" code. The closest are Ctrl+C aka
> ETX for End of Transmission, and Ctrl+D aka EOT for End of Text.
>
> Ross Berteig r...@cheshireeng.com
> Cheshire Engineering Corp. http://www.CheshireEng.com/
>
> ___
> 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] crnl-setting bug

[Scott Robison]

I believe the glob-style wildcard pattern matching is being performed
by mingw during program startup before handing control over to main
(because cmd.exe does not do wildcard expansion itself in either
Windows 7 or XP).

SDR

On Thu, Apr 7, 2011 at 10:53 AM, Konstantin Khomoutov
 wrote:
> On Thu, 7 Apr 2011 15:44:12 +
> "Wilson, Ronald"  wrote:
>
>> PS C:\Users\rwilso20> cmd
>> Microsoft Windows [Version 6.0.6002]
>> Copyright (c) 2006 Microsoft Corporation.  All rights reserved.
>>
>> C:\Users\rwilso20>cd \rev\src\fossil
>>
>> C:\rev\src\fossil>fossil setting crnl-glob "*"
>> Usage: C:\rev\src\fossil\fossil.exe setting ?PROPERTY? ?VALUE?
>
> I asked a fellow user of Windows 7 to test the version available from
> the downloads page (which I used under Windows XP) and he confirms the
> problem you're seeing.
> ___
> 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] crnl-setting bug

[Scott Robison]

On Thu, Apr 7, 2011 at 1:16 PM, Scott Robison  wrote:
> I believe the glob-style wildcard pattern matching is being performed
> by mingw during program startup before handing control over to main
> (because cmd.exe does not do wildcard expansion itself in either
> Windows 7 or XP).

Bah, stupid gmail (or stupid user of gmail). Anyway, if you type

fossil setting crnl-glob *

at a command prompt in an empty directory (no expansion opportunity
for *) you get a different result than if you type that command in a
non-empty directory (where * is expanded into the list of entries in
the current directory). The mingw startup code is emulating the
behavior one expects from a posix environment.

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] crnl-setting bug

[Scott Robison]

On Thu, Apr 7, 2011 at 1:24 PM, Ron Wilson  wrote:
> On Thu, Apr 7, 2011 at 3:16 PM, Scott Robison  wrote:
>> I believe the glob-style wildcard pattern matching is being performed
>> by mingw during program startup before handing control over to main
>> (because cmd.exe does not do wildcard expansion itself in either
>> Windows 7 or XP).
>
> And, I would guess that cmd.exe is stripping off the "s.
>
> So, maybe:
>
> fossil setting crnl-glob "'*'"
>
> would work. After cmd.exe strips off the "s, 's would still be there
> to protect the * from mingw.

Ah, excellent point. cmd.exe strips quotes so that there is a way to
embed separator characters such as space in a command line argument.

In any case, I just tested and it appears that using single quotes
instead of double quotes is sufficient to get the asterisk through the
command line processing software stack.

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] crnl-setting bug

[Scott Robison]

On Thu, Apr 7, 2011 at 2:44 PM, Wilson, Ronald  wrote:
>>
>> Confirmed. Single quotes work on Win7.
>>
>
> Actually, single quotes don't work either because the single quotes get 
> preserved in fossil:

According to http://gnuwin32.sourceforge.net/compile.html:

Filename globbing

Wildcards on the command-line are expanded by the command-line
interpreter. If you wish to disable this filename globbing, then add

int _CRT_glob = 0;

to the beginning of the main program file.

Perhaps this will be necessary for Windows builds.

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] [vb.net] Which files/folders can be safely ignored?

[Scott Robison]

I think it's more a question of how you're using fossil. If you are
using it for an actual distributed project, then you probably don't
(or at least might not want) to include suo files. If you are using it
just for vcs as a solo developer, there is no technical reason not to
include the suo file.

SDR

On Mon, Oct 3, 2011 at 9:46 AM, Tomek Kott  wrote:
> The way I see it, you don't want the user options travelling between
> different users, since they're user options. I don't believe they set
> anything important for the solution itself. At least, that's how I
> understand it.
>
> Tomek
>
> On Mon, Oct 3, 2011 at 11:33 AM, tpero...@compumation.com
>  wrote:
>>
>> I also ignore the obj folder. All those files get rebuilt anyway. You
>> might want to keep the suo file:
>>
>> What is an suo file?
>>
>>
>>
>> Tony Perovic
>>
>> Compumation, Inc.
>>
>>
>>
>> From: fossil-users-boun...@lists.fossil-scm.org
>> [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Tomek Kott
>> Sent: Monday, October 03, 2011 9:56 AM
>> To: fossil-users@lists.fossil-scm.org
>> Subject: Re: [fossil-users] [vb.net] Which files/folders can be safely
>> ignored?
>>
>>
>>
>> for C++ projects based in VS2008/10, I have the following ignore glob,
>> which seems to work pretty well:
>>
>> *.vcxproj.user,*Debug/*,*.suo
>>
>> Probably you can replace vcx with vb. Of course, YMMV.
>>
>> I ignore the debug folders since these are used when building, and I
>> assume I can just build things again to get back the exe from the source.
>>
>> Hope that helps,
>>
>> Tomek
>>
>> On Mon, Oct 3, 2011 at 9:59 AM, Gilles  wrote:
>>
>> Hello
>>
>>        I'd like to start using Fossil to monitor Vb.Net (2008 Express)
>> projects, and need to know which files/folders I can safely ignore
>> when using the "add" command.
>>
>> FWIW, here's a one form + one module project:
>> 
>> Directory of C:\Projects\MyApp\WindowsApplication1
>>
>> 03/10/2011  15:04             3.040 Form1.Designer.vb
>> 03/10/2011  15:04             5.814 Form1.resx
>> 03/10/2011  15:08             2.903 Form1.vb
>> 03/10/2011  13:40               194 Module1.vb
>> 03/10/2011  13:36              bin
>> 03/10/2011  13:36              My Project
>> 03/10/2011  13:36              obj
>> 03/10/2011  13:36               934 WindowsApplication1.sln
>> 03/10/2011  13:36             5.678 WindowsApplication1.vbproj
>> 03/10/2011  13:36                74 WindowsApplication1.vbproj.user
>>
>> Directory of C:\Projects\MyApp\WindowsApplication1\bin\Debug
>> 03/10/2011  15:08            27.648 WindowsApplication1.exe
>> 03/10/2011  15:08            58.880 WindowsApplication1.pdb
>> 03/10/2011  15:08            14.328 WindowsApplication1.vshost.exe
>> 03/10/2011  15:08               127 WindowsApplication1.xml
>>
>> Directory of C:\Projects\MyApp\WindowsApplication1\bin\Release
>>               0 File(s)              0 bytes
>>
>> Directory of C:\Projects\MyApp\WindowsApplication1\My Project
>> 03/10/2011  02:51             1.522 Application.Designer.vb
>> 03/10/2011  02:51               510 Application.myapp
>> 03/10/2011  02:51             1.199 AssemblyInfo.vb
>> 03/10/2011  02:51             2.807 Resources.Designer.vb
>> 30/07/2008  06:54             5.612 Resources.resx
>> 03/10/2011  02:51             3.058 Settings.Designer.vb
>> 30/07/2008  06:54               279 Settings.settings
>>               7 File(s)         14.987 bytes
>>
>> Directory of C:\Projects\MyApp\WindowsApplication1\obj\Debug
>> 03/10/2011  10:56             6.069 ResolveAssemblyReference.cache
>> 03/10/2011  13:36              TempPE
>> 03/10/2011  15:08            27.648 WindowsApplication1.exe
>> 03/10/2011  15:04               180
>> WindowsApplication1.Form1.resources
>> 03/10/2011  14:30               180
>> WindowsApplication1.Form2.resources
>> 03/10/2011  15:08            58.880 WindowsApplication1.pdb
>> 03/10/2011  13:40               180
>> WindowsApplication1.Resources.resources
>> 03/10/2011  15:08             2.764
>> WindowsApplication1.vbproj.FileListAbsolute.txt
>> 03/10/2011  15:04               905
>> WindowsApplication1.vbproj.GenerateResource.Cache
>> 03/10/2011  15:08               127 WindowsApplication1.xml
>>               9 File(s)         96.933 bytes
>>
>> Directory of C:\Projects\MyApp\WindowsApplication1\obj\Debug\TempPE
>> 03/10/2011  13:02             7.680 My
>> Project.Resources.Designer.vb.dll
>>               1 File(s)          7.680 bytes
>>
>> Directory of C:\Projects\MyApp\WindowsApplication1\obj\Release
>>               0 File(s)              0 bytes
>> 
>>
>> 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/fossi

Re: [fossil-users] Announcement Fuel 0.9.6

[Scott Robison]

>> A small request: with an announcement like this, can you please include an
>> indication what Fuel is?
> Sure.
> Fuel is a Qt-based cross-platform GUI front-end to Fossil.
>
> As this isn't the first time I mentioned Fuel on this list, I didn't
> think people
> wouldn't know what it was about. Maybe new members of the list?

We all come across a lot of information. Even if we saw Fuel
previously it does not mean we'll remember it. Even a tiny change to
your original post could have cleared things up, such as:

The latest version of Fuel has been released! -> The latest version of
Fuel, a GUI for Fossil, has been released!

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] Trac-to-Fossil Was: Wysiwyg wiki editing. Was: Side-by-side wiki editing?

[Scott Robison]

> On 15 May 2012 03:01, Ron Wilson  wrote:
> Trac's versioning for wiki and issues is native to Trac, and is used
> solely for the wiki and issues. The version control of the source for
> a project is entirely separate.
>
> Trac does not use your source control choice for issues or wiki.

Though as I recall, the (default at least) database is SQLite. :)
___
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] Trac-to-Fossil Was: Wysiwyg wiki editing. Was: Side-by-side wiki editing?

[Scott Robison]

On Tue, May 15, 2012 at 8:55 PM, Richard Hipp  wrote:
>> Though as I recall, the (default at least) database is SQLite. :)
>
>
> The connections run much deeper.  See
> http://trac.edgewall.org/wiki/TracHistory for a brief history of Trac.
> Never heard of CVSTrac?  Try using "ping" to find the IP address of
> www.cvstrac.org.  Now do the same with www.sqlite.org and
> www.fossil-scm.org.

I was aware of CVSTrac as I knew it was used for SQLite prior to
Fossil, though I wasn't aware of which way the connections ran. Thanks
for the link to answer that question I've been too lazy to look up
myself. :)

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] "losing" history in private branch merge?

[Scott Robison]

On Fri, May 25, 2012 at 12:26 PM, Nolan Darilek  wrote:
> Shame, I actually kind of liked that individual commits were preserved.
> Squashing and such was part of why I left Git. History should be preserved,
> whether you are working alone in private or in the open.

History is preserved in your private branch for your private perusal,
isn't it? To borrow some C++ lingo, it sounds like what you're looking
for might be better called a 'protected' branch. Or if necessary
disable auto-sync and publicly branch until you're done with it,
optionally on another clone of the repository. Or probably other
things I can't think of at the moment.

The desired functionality is there, just not the way you were
expecting it, probably.

Note: I don't mean for the above to come off terse or rude or
condescendingly. Just observing some other possible solutions that
haven't been mentioned yet that will publicly preserve history in a
way that works with the existing system.

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] source code file is considered by fossil to be binary.

[Scott Robison]

It might be better (more portable) to escape those as octal or hex
sequences (like '\002' or '\x02').
On Jun 24, 2012 3:11 PM, "James Bremner"  wrote:

> Richard Hipp  writes:
>
> >  In your case there is a Ctrl-B (ascii 0x02) in the 2150th byte of the
> file,
> > which makes Fossil think it is a binary file.
>
> Thank you for clarifying this mystery.
>
> FYI: ascii 0x02 is STX = Start of Text  It is used by many devices that
> communicate over RS232 to demark the beginning if a message.  This code is
> used to parse messages from such devices and so the character is sprinkled
> all
> through it.
>
> Other such codes freuently used are:
>
> 1   001 01  0001SOH Start of Heading
> 2   002 02  0010STX Start of Text
> 3   003 03  0011ETX End of Text
> 4   004 04  0100EOT End of Transmission
>
> James
>
>
> ___
> 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] Fossil 1.23

[Scott Robison]

I downloaded the lastest Windows fossil build tonight and am giving DVCS
another shot. Some notes:

1. I like the fact that I could --date-override the initial create date
stamp.
1a. I wish that I could --date-override a commit at the command line so
that I didn't have to edit the date stamp via the web interface later.
1b. If you don't type the date stamp format just right, fossil will crash
trying to display the time line in the web interface. In my case I typed
"8:12:23" instead of "08:12:23" for the edited time, omitting the leading 0.

2. I am color blind. The color coding of bullet points in the "Edit User"
pages explaining which marks indicate what is practically worthless to me
(I spent a while staring at them trying to figure out what the difference
was; I'm not complaining, it's just my burden, and I'm fortunately to not
have worse burdens, really). I mention this only as a usability issue for
someone to consider. I really don't know what would be better, and hate to
be one of those people that sounds like "accommodate my disability even
though it works for most people just fine!" Some obvious alternatives that
pop into my head are to use multiple bullet shapes instead of just color
coding the same shape or to use subscript or superscript digits or some
such.

3. I would be happy to take a stab at modifying the source to implement the
stuff above, and I understand there is some sort of copyright assignment or
waiver form to be filled out... If someone could forward that my way I
would appreciate it.

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 1.23

[Scott Robison]

Ah, then perhaps my first edit will be to document the undocumented rather
than implement the unimplemented. :) To answer your question, yes I am
converting a smallish multipurpose svn repository I've been using for about
three years. It has multiple projects in it that I don't want to all
migrate to a single fossil repo, so this exercise has two benefits for me.
One, it allows me to cherry pick (as it were) which svn sub-trees to move
into each fossil repo. Two, it gives me a little artificial early
experience using fossil to build up the new repo mostly like I would have
over the last few years.

As for the color coding, I was not referring to branch colors, I was
referring to colors used to highlight bullet characters in an admin/config
page. For me it is especially hard to see the color changes that only apply
to occasional foreground characters. It is information I can get elsewhere,
but making and submitting a change to modify the character as well as color
seemed like a potentially useful little project not just for me but for the
community as well (or at least the color blind subset of the community).

Thanks for the info!

SDR
On Aug 25, 2012 2:57 AM, "Rene"  wrote:

> On 2012-08-25 09:47, Scott Robison wrote:
>
>> I downloaded the lastest Windows fossil build tonight and am giving
>> DVCS another shot. Some notes:
>>
>> 1. I like the fact that I could --date-override the initial create
>> date stamp.
>> 1a. I wish that I could --date-override a commit at the command line
>> so that I didn't have to edit the date stamp via the web interface
>> later.
>> 1b. If you don't type the date stamp format just right, fossil will
>> crash trying to display the time line in the web interface. In my case
>> I typed "8:12:23" instead of "08:12:23" for the edited time, omitting
>> the leading 0.
>>
>> 2. I am color blind. The color coding of bullet points in the "Edit
>> User" pages explaining which marks indicate what is practically
>> worthless to me (I spent a while staring at them trying to figure out
>> what the difference was; I'm not complaining, it's just my burden, and
>> I'm fortunately to not have worse burdens, really). I mention this
>> only as a usability issue for someone to consider. I really don't know
>> what would be better, and hate to be one of those people that sounds
>> like "accommodate my disability even though it works for most people
>> just fine!" Some obvious alternatives that pop into my head are to use
>> multiple bullet shapes instead of just color coding the same shape or
>> to use subscript or superscript digits or some such.
>>
>> 3. I would be happy to take a stab at modifying the source to
>> implement the stuff above, and I understand there is some sort of
>> copyright assignment or waiver form to be filled out... If someone
>> could forward that my way I would appreciate it.
>>
>> SDR
>>
> There is a non documented option to commit to override date and user
> --date-override
> --user-override
>
> Why do you want to override the date? Are you converting a repository?
>
> What the colour coding does is, in de case of multiple branches,
>
> is that a commit square gets the same colour as the comment
> The left side is always the trunk. E.g.
>
>  [ ]   These are on the trunk and has no colour
>   |
>   |
>   |  [g]   This text has the colour green
>   |   |
>   |   |
>   |   |
>   |   [p]   This text has the colour purple
>
>
> It is helpful aid to see on which branch activity is going on. But you can
> get that information also by
> looking at the squares.
>
> Maybe we could number or symbolise the branches in addition to the
> colouring like
>
>
> 2012-08-24  |
>  14:50  |   [2]  2 [b4ea94b488] Leaf: merge unicode branch (user:
> jan.nijtmans, tags: eclipse-project)
> |   /|
> |  / |
> | /  |
> |/   |
>  13:42  |  [3]   |3 [c780793749] Leaf: add mkdir to the
> unicode-supported functions add chinese-named file and
> |   ||  directory in test directory, demonstrating the
> fix (user: jan.nijtmans, tags: unicode)
> |   ||
>  13:15  |  [3]   |3 [d8e1431fc0] Better support for unicode
> filenames on Win32 (Not tested on
> |   ||  other platforms yet, will not work!) (user:
> jan.nijtmans, tags: unicode)
> |   ||
> |  / |
> | /  |
> |/   |
>  08:16  +---[2]   2 [abbc00fc5b] Mer

Re: [fossil-users] Fossil 1.23

[Scott Robison]

Thanks for the info. I was going to tackle that myself today so that I
could get that benefit, and appreciate the pointers. Of course, submitting
it (along with eventual paperwork) gives me 'practical experience' with
pushing stuff back to a master repo (where my current personal project
needs won't involve much or any of the d in dvcs) and the warm fuzzy of
contributing to the project in some small way.

SDR
On Aug 25, 2012 3:17 AM, "Francis Daly"  wrote:

> On Sat, Aug 25, 2012 at 01:47:44AM -0600, Scott Robison wrote:
>
> Hi there,
>
> > 2. I am color blind. The color coding of bullet points in the "Edit User"
> > pages explaining which marks indicate what is practically worthless to me
>
> I think that is, "fossil ui" in an open checkout, then in the browser
> click Admin, Users, then the specific User ID, to get to a url very
> like http://localhost:8080/setup_uedit?id=1
>
> > Some obvious alternatives that
> > pop into my head are to use multiple bullet shapes instead of just color
> > coding the same shape or to use subscript or superscript digits or some
> > such.
>
> If it's the page mentioned above, then the source code is in
> src/setup.c. Look for the word "ueditInheritDeveloper" (in two places)
> and change "•" after it to, say, "◊ " in the first place,
> and "◊" in the second. (There's an extra space in the first one,
> to make it display clearer.)
>
> Then do something very similar for ueditInheritReader,
> ueditInheritAnonymous, and ueditInheritNobody -- perhaps "†",
> "‡", and leave the other one as "•"?
>
> Then rebuild and test that the changes (a) break nothing; and (b)
> improve something.
>
> And then use that as your version of fossil.
>
> > 3. I would be happy to take a stab at modifying the source to implement
> the
> > stuff above, and I understand there is some sort of copyright assignment
> or
> > waiver form to be filled out...
>
> You can do what you like with your version of the code. The copyright form
> is for when you wish to have your changes included in the main repository.
>
> And the specific change above is a local display one, so you can get
> the benefit today and worry about the paperwork later ;-)
>
> Cheers,
>
> f
> --
> Francis Dalyfran...@daoine.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 1.23

[Scott Robison]

I'm not much of a visual/ui design guy but I'll see what I can come up with.

SDR
On Aug 25, 2012 9:09 AM, "Richard Hipp"  wrote:

>
>
> On Sat, Aug 25, 2012 at 10:25 AM, Scott Robison wrote:
>
>>
>> As for the color coding, I was not referring to branch colors, I was
>> referring to colors used to highlight bullet characters in an admin/config
>> page.
>>
> That whole colored-dot thing on the users page is hokey and needs to be
> completely reworked.  The page needs to be redesigned from the ground up.
> I just haven't done so yet because it is a seldom-used page and I've been
> distracted with more pressing issues.
>
> You are welcomed to give it a go.
>
> --
> 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] How to save typing when checking out branches with long names?

[Scott Robison]

Just throwing out a couple of ideas:

fossil globco 154

Or perhaps slightly less bad:

fossil co --glob 154

Though I'm not personally looking for this functionality myself so not
having it as an official feature doesn't bother me.

SDR

On Mon, Aug 27, 2012 at 11:00 AM, Richard Hipp  wrote:

>
>
> On Mon, Aug 27, 2012 at 12:35 PM, Stephan Beal wrote:
>
>> On Mon, Aug 27, 2012 at 6:07 PM,  wrote:
>>
>>> I'd be very happy if I could just type:
>>>
>>> $ fossil co vim-7.3.154
>>>
>>> I'd be even happier if I could just type:
>>>
>>> $ fossil co 154
>>>
>>
>> Not to sound too pessimistic, but...
>>
>>
> Yeah.  I can't quite put my finger on why, but something just feels wrong
> about doing prefix matching against tag names.  I wouldn't be that hard to
> implement, actually (thanks to having SQLite with a GLOB operator as the
> storage engine) but I'm questioning the wisdom of doing so.  You're really
> going to need to sell this proposal if you want it to get into the tree.
>
>
> --
> 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] How to save typing when checking out branches with long names?

[Scott Robison]

The essence of my suggestion was to not do it by default but to provide a
simple way for the user to say "yes, I really want you to search for this
substring anywhere" rather than forcing it on everyone.

SDR

On Mon, Aug 27, 2012 at 11:24 AM, Stephan Beal wrote:

> On Mon, Aug 27, 2012 at 7:18 PM, Scott Robison wrote:
>
>> fossil co --glob 154
>>
>> Though I'm not personally looking for this functionality myself so not
>> having it as an official feature doesn't bother me.
>
>
>
> FWIW: as Richard said, it's _technically_ easy, but brings with it both
> philosophical and usability concerns. Fossil would need a way of allowing
> the user to disambiguate, e.g.:
>
> "possible matches:
> 1) ...
> 2) ...
> type number to continue..."
>
> and that type of feature would then arguably need to be added to other
> commands which deal with branches/tags.
>
> IMO a custom shell-based solution is the proper place for this. If it can
> be demonstrated that this is feasible, i'll stop being pessimistic about it
> ;). i suspect, however, that any attempt at doing so would reveal worms
> which haven't yet been mentioned.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
>
> ___
> 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 Win9x?

[Scott Robison]

Even if someone is still supporting Win9X, it does not necessarily follow
that they are doing anything more that testing binaries in that
environment. I would not be heartbroken if such support were removed.

SDR
On Sep 13, 2012 8:25 AM, "Jan Danielsson" 
wrote:

> On 09/13/12 16:02, Richard Hipp wrote:
> > Is there any reason to try to keep Fossil working on windows9x?
>
>I don't think much Win9x development goes on today. But even if I'm
> wrong, I would guess that the intersection between the sets "Win9X
> developers" and "Fossil users" is roughly empty.
>
>Tag last win95-compatible version so anyone so inclined can dig it up
> easily, just in case?
>
> --
> Kind regards,
> Jan Danielsson
>
>
>
> ___
> 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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Scott Robison]

I'd like to assist with that contribution. Assuming someone hasn't already
done it by the time I click send. :)

SDR

On Thu, Sep 13, 2012 at 2:08 PM, Richard Hipp  wrote:

>
>
> On Thu, Sep 13, 2012 at 3:45 PM, Richard Hipp  wrote:
>
>>
>>
>> On Thu, Sep 13, 2012 at 3:43 PM, Kevin Greiner wrote:
>>
>>>
>>> I'm using fossil 1.23 on Windows 7. I'm attempting to store text files
>>> generated by Microsoft SQL Server 2012 in fossil so I can easily track
>>> their changes over time.
>>>
>>> The problem is that fossil thinks these generated text files are binary
>>> data which prevents me from viewing the files via the web ui and generating
>>> diffs.
>>>
>>> When I look at these files in a hex edtor, I see this: ff fe 53 00 45
>>> 00 54 00 20 00 41 00. A text editor shows "SET A".
>>>
>>> I've looked in the email list archive where DRH specifies that a null
>>> character or a line longer than 8192 chars. The entire file is 1074 bytes
>>> so it's not the length. Is fossil reading the 00 bytes as nulls?
>>>
>>> Any idea why fossil thinks these files are binary? And, more
>>> importantly, what encoding I can specify to prevent this? I've tried
>>> various permutations of ASCII, UTF8, UTF7 to no effect.
>>>
>>
>> The file itself appears to be in utf16le.  The "diff" facilities in
>> Fossil currently only know how to deal with utf8.
>>
>
> It would be an interesting project to enhance Fossil so that it could
> support UTF16 in addition to UTF8.  What would be needed is an algorithm to
> detect when a file was UTF16.  (The BOM at the beginning of Kevin's example
> ought to be a big hint.)  Then automatically call a convert routine to
> generate UTF8 prior to passing the content into the diff logic, or into the
> wiki engine, or prior to display on the UTF8 webpage, etc.
>
> Basically, we need a routine that converts an in-memory buffer from UTF16
> to UTF8, and leaves anything that isn't UTF16 unchanged.  Then we need to
> call that routine in a few strategic places inside of Fossil
>
> Volunteers to write that routine?  I'll help identify the places where it
> needs to be called.
>
>
>>
>>
>>>
>>> Thanks,
>>>
>>> Kevin
>>>
>>> ___
>>> fossil-users mailing list
>>> fossil-users@lists.fossil-scm.org
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>>
>>
>>
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>>
>
>
>
> --
> 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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Scott Robison]

I assumed (dangerous though it may be) that "leaves anything that isn't
UTF-16 unchanged" meant "don't convert any buffer to UTF-8 if the
origination buffer is not UTF-16".

SDR

On Thu, Sep 13, 2012 at 5:04 PM, David Given  wrote:

> On 13/09/12 21:08, Richard Hipp wrote:
> [...]
> > Basically, we need a routine that converts an in-memory buffer from
> > UTF16 to UTF8, and leaves anything that isn't UTF16 unchanged.  Then we
> > need to call that routine in a few strategic places inside of Fossil
>
> Could you clarify what you mean by 'leaves anything that isn't UTF-16
> unchanged'? Do you mean you just want it to convert up until the point
> where it finds non-well-formed UTF-16 and then tells you where it
> stopped, or do you actually want to leave the unconverted UTF-16 in the
> output file? Because that last will just produce gibberish ---
> non-well-formed UTF-8.
>
> The standard way to do all these conversions is just to call out to
> iconv, which handles all the horrible edge cases. It is available for
> Windows, but it's not small.
>
> OTOH if you don't care about the edge cases, converting well-formed
> UTF-16 to UTF-8 is lossless and pretty straightforward.
>
> --
> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
> │
> │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
> │ --- Conway's Game Of Life, in one line of APL
>
>
> ___
> 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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Scott Robison]

So I've spent some time writing a small and I think portable routine to
detect if a buffer is a valid UTF-16 (either little or big endian). It
rejects buffers if they contain an odd number of bytes or contain any of
the 66 non-character code-points or have invalid surrogate usage. While
this seems to work well on the handful of binary files I've tested it
against, I'm curious as to whether it would be desired to additionally use
some or all of the current binary file detection criteria? My thought being
that a file could be perfectly valid UTF-16 but have an extremely long line
or (worse in my opinion) embedded non-text characters (particularly U+
or non-white-space control codes).

SDR

On Thu, Sep 13, 2012 at 6:07 PM, Richard Hipp  wrote:

> You assume correctly.
>
> The use of iconv won't do, though, since everything also needs to work on
> Unix.  There are small, portable conversion routines in SQLite that you can
> copy.
>
> D. Richard Hipp - d...@sqlite.org
> Sent from phone - pardon brevity
>
> On Sep 13, 2012 7:44 PM, "Scott Robison"  wrote:
>
> I assumed (dangerous though it may be) that "leaves anything that isn't
> UTF-16 unchanged" meant "don't convert any buffer to UTF-8 if the
> origination buffer is not UTF-16".
>
> SDR
>
> On Thu, Sep 13, 2012 at 5:04 PM, David Given  wrote:
>
>> >
>> > On 13/09/12 21:08, Richard Hipp wrote:
>> > [...]
>> > > Basically, we need a routine that converts an...
>>
>> > ___
>> > fossil-users mailing list
>> > fossil-users@lists.f...
>>
>
>
> ___
> 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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Scott Robison]

On Fri, Sep 14, 2012 at 5:46 AM, Richard Hipp  wrote:

>
> Detection of embedded non-printing characters, especially U+, would be
> nice.
>
> Should we insist on a BOM at the beginning of the file?
>

I don't think a BOM should be mandatory, as it is not required by Unicode.
Another thought:

Unicode characters have a General Category. The categories Letter, Mark,
Number, Punctuation, Symbol & Separator are obviously useful in the context
of Unicode encoded text files. That leaves the "Other" categories:

1. "Other, control": Some of these are useful in the context of text files
(tab, CR, LF, FF among others which are used to format text). Some not so
much. I'd think however fossil currently classifies such characters in
8-bit text is how they should be treated for Unicode.

2. "Other, format": I believe these should be included even though I think
they'd be rare in the types of files fossil would need to diff.

3. "Other, surrogate": If these appear in an invalid context in a document
it is not well formed UTF-16.

4. "Other, not assigned [Noncharacter]": If these appear anywhere in a
document it is not well formed UTF-16.

5. "Other, private use": Should we allow these in a file that fossil might
diff? Since they are private-use there is no 'standard' way of displaying
them, but people may legitimately want or need them in their private
documents.

6. "Other, not assigned [Reserved]": These are perfect valid code points,
and over time more of them will be allocated to other categories. We can
either allow them knowing they won't be displayable now but might be later
or restrict them until some future time. Either way the code has to be kept
up to date with future Unicode revisions, as a new code could be allocated
to a printable character or (theoretically) to a non-printable control code.

I'm assuming the desire for identifying UTF-16 and converting to UTF-8 is
*only* for the purposes of recognizing them as diffable text vs binary
files (though you might also want to use this to identify a file as Unicode
text vs 8-bit text vs binary when adding them to the repository). If the
first thought is correct, it would be possible to "expand" normally
non-printable characters into printable sequences in otherwise valid UTF-16
buffers. For example:

Let's say a line of text in a file has an embedded backspace character
(U+0008). We could say it is not a text file for that reason or we could
expand the normally non-printing backspace into literal text "U+0008". That
might be more valuable in the context of diffing files, and it causes no
harm in that the file as stored in the file system or the repository
remains unchanged.

Hopefully I'm not rambling and these thoughts are sufficiently coherent as
to make sense...

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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Scott Robison]

On Fri, Sep 14, 2012 at 8:20 PM, Csaba Kos  wrote:

> I think now would be a good time to discuss the possibility of a more
> generic
> text conversion framework, i.e. not only UTF16 to UTF8 but also SHIFT-JIS
> to UTF8, and so on. Also CR+NL to NL conversion could be handled by such
> framework as well. One possibility is to support calling of an external
> command
> which could be specified in some "...-glob" setting.
>
> I'm not a git user, but as far as I know, git has a generic text
> filtering framework that is capable of the above.
>

One thing I thought of yesterday but dismissed (and am now rethinking as a
result of your email) is maybe there should be a bit of meta-data that can
be attached to files to explicitly set their encoding. Having built in
detection code would still be useful to set it initially, and having it as
meta-data could make it possible for the user to change the encoding of the
file when fossil guessed wrong for whatever reason. A similar bit of
functionality could be provided for end of line handling. Regardless, I am
a fossil novice myself, so maybe that functionality is there and I am just
ignorant of it.

Regardless, having some basic UTF-16 to UTF-8 conversion built in is
helpful in advancing the goal of providing base functionality that is
available on all platforms without need to install or configure extra
tools. It would certainly be cool to provide some sort of hook to access
external tools that could handle transcoding from more encodings as needed.
Maybe options to build with ICU (much as SQLite provides) could provide
what you're describing for those that want it, and in the case that ICU is
not available, built in diffing is limited to those base supported
encodings...

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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Scott Robison]

On Fri, Sep 14, 2012 at 11:34 PM, Csaba Kos  wrote:

> I am a fossil novice myself, but I don't think there is such
> functionality built-in currently.
>

I was talking about tagging encoding as well as end of line handling, but
mainly I was giving myself an out in case I was speaking in favor of
something that already exists. :)


> My plan for the EOL conversion was to extend the syntax of the
> "crnl-glob" setting in the following way:
> *.txt:cr< force CR
> *.txt:nl< force NL
> *.txt:cr+nl   < force CR+NL
> *.txt:native  < convert to native format
> anything else: < allow CR+NL (current behaviour)
>
> But I agree that properties attached to files (similarly to
> subversion, perhaps) might be preferable for setting the encoding/line
> ending.
>

 That was my thought as well.

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] Latest stable release or dev release does not compile with option: --static

[Scott Robison]

While I agree that the -Dstrcmp... solution is inadequate, strcmp is
subject to the system locale setting. While it might default to the C
locale (giving the expected binary comparison behavior), it might not.
One may not consider locale the same as localization, but whatever you
choose to call it, it can result in non-deterministic behavior based
on the exact system configuration.

SDR

On Wed, Jan 30, 2013 at 8:19 AM, Richard Hipp  wrote:
>
>
> On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans 
> wrote:
>>
>> 2013/1/30 Sergei Gavrikov :
>> > [FYI]
>> >
>> > An optimized (-O2) default build with entered substitution
>> > -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux
>> ...
>> >   Program received signal SIGSEGV, Segmentation fault.
>> ...
>>
>> Thanks! That's fully explainable: When setting -Dstrcmp=fossil_strcmp
>> before including , and strcmp has a decoration that its
>> arguments are non-null, that is used by the optimizer to remove
>> the two first if's from the fossil_strcmp function: if its arguments
>> cannot be NULL, that's a valid optimization
>>
>> Should be fixed now, by #undef'fing fossil_strcmp in printf.c
>
>
> I'm uncomfortable with this change.  If we need to use fossil_strcmp()
> everywhere (which surprises me, since strcmp() should *not* be subject to
> localization) then we should do so explicitly, and not depend on
> preprocessor magic, as the preprocessor magic will likely cause maintenance
> headaches down the road, and/or introduce subtle bugs such as the above.
>
>
>>
>>
>> Many Thanks!
>>
>> Regards,
>>Jan Nijtmans
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
>
>
> --
> 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] Latest stable release or dev release does not compile with option: --static

[Scott Robison]

And never mind, I guess I was wrong. Not sure why I couldn't have
checked that *before* clicking send, but c'est la vie.

SDR

On Wed, Jan 30, 2013 at 8:19 AM, Richard Hipp  wrote:
>
>
> On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans 
> wrote:
>>
>> 2013/1/30 Sergei Gavrikov :
>> > [FYI]
>> >
>> > An optimized (-O2) default build with entered substitution
>> > -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux
>> ...
>> >   Program received signal SIGSEGV, Segmentation fault.
>> ...
>>
>> Thanks! That's fully explainable: When setting -Dstrcmp=fossil_strcmp
>> before including , and strcmp has a decoration that its
>> arguments are non-null, that is used by the optimizer to remove
>> the two first if's from the fossil_strcmp function: if its arguments
>> cannot be NULL, that's a valid optimization
>>
>> Should be fixed now, by #undef'fing fossil_strcmp in printf.c
>
>
> I'm uncomfortable with this change.  If we need to use fossil_strcmp()
> everywhere (which surprises me, since strcmp() should *not* be subject to
> localization) then we should do so explicitly, and not depend on
> preprocessor magic, as the preprocessor magic will likely cause maintenance
> headaches down the road, and/or introduce subtle bugs such as the above.
>
>
>>
>>
>> Many Thanks!
>>
>> Regards,
>>Jan Nijtmans
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
>
>
> --
> 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] Automation

[Scott Robison]

My apologies if this is too long for reading, but I hope you'll bear with
me.

I like the idea behind chiselapp, but am paranoid so I want to host
something similar for myself (and just myself) to keep things private. I
downloaded chiselapp and while it *could* work, I decided it was "more"
than I really needed, plus it is Apache centric and I run lighttpd. I have
"ported" configuration files from apache to lighttpd in the past, but just
didn't want to bother with it in this case.

To that end, I've started creating a few basic scripts to give me a front
end to fossil from a protected webpage on a secured server. I have a
directory with an index.php which enumerates a directory full of fossils
and gives me simple links to each fossil. I have a two line fossil cgi
script that gives me access to those repos. I've even created a little page
to allow me to change a password for a single user across all repos at one
time.

My next goal is to script the creation of a new repository. I have the
"basics" down, in that I can easily use a form to get the needed command
line parameters and run a script to create the new repo. I'd like to go a
little further with it and set the project name & description, default
permissions, and so on.

It does not appear there is a command line based way to set certain
configuration options. I've dumped repos with "sqlite3 repo.fossil .dump"
to see how certain things work. To accomplish my goal:

1. Is there a fossil command line based way to set config options
(particularly project name and description) that I'm unaware of?

2. If there is not, is this something that could be done with the json api
via cli as it exists today?

3. If the json api is not an option at present, what is the significance of
the mtime field in the config table? Must it be set to some particular
valid value or would an initial value of "0" be okay. If that is the case
(or the proper default value is easily obtained / computed) I could easily
just use a little SQL to set the needed config table values.

FWIW, this is very plain looking stuff (I'm not a web guy at all) but I'd
be happy to share the scripts and such when I'm finished. Probably the most
useful part is just the scripts in the directory that give a front end that
enumerates the existing repositories.

-- 
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] Automation

[Scott Robison]

On Fri, May 9, 2014 at 1:21 AM, Stephan Beal  wrote:
>
> On Fri, May 9, 2014 at 9:15 AM, Scott Robison 
wrote:
>>
>> links to each fossil. I have a two line fossil cgi script that gives me
access to those repos. I've even created a little page to allow me to
change a password for a single user across all repos at one time.
>
>
> Would you mind sharing that one with us?

The fossil cgi script is just based on the one documented elsewhere, so I
assume you mean the password change script. You can see it at
http://tny.cz/2376d7fa (tinypaste, tny.cz). When the page is accessed via
http GET it just displays the page and any optional message that might have
been passed as a url parameter. When the info is filled in and the form is
POSTed, it does basic validation of the username and passwords. If all is
okay, it uses a foreach loop to enumerate all the fossil files in the hard
coded directory, runs the fossil command to change the password for the
given user on each, and redirects back to the main index with a message. If
it detects errors with the username or password, it redirects back to
itself with simple messages to give the user a chance to do it again.

As I said in my original message, I'm not a web guy, so this is definitely
not "professional grade". It lives behind a protected directory so I'm the
only one with access to it, so robustness and aesthetically pleasing were
not my primary considerations. Just something to help automate some things
that I continually have to look up whenever I need to do them. If I were
looking for a place to host something open source, I'd just go to chiselapp
(or expose a repository via a specific unprotected url). In my case:

http://www.webducky.com/dev/ -> run a front end index script to provide a
menu of all the fossils
.../dev/project -> bash script to set the home environment variable and
then...
.../dev/fossil-cgi -> fossil cgi script. It could be named project
directly, but the settings don't work unless the home directory is set
first, and this was the "easiest" way for me to figure out how to do it.
.../dev/password.php -> the below script linked to from /dev/
.../dev/blah.php -> other scripts to be written / finished to create,
rename, delete repos.

Note there are no copyrights or licenses claimed in the code itself, as I
didn't really intend to share it, though I don't mind sharing it. In any
case, it is simple enough and non-strategic enough that consider I it
public domain, so do with it what you will and realize there is no warranty
(not that you could easily prove I was the one who provided it anyway,
maybe I just found the link and am claiming it as my own creation). ;) Not
nearly as useful or complex as SQLite, but hey, I'm not nearly as bright as
DRH either.

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] Automation

[Scott Robison]

On Fri, May 9, 2014 at 1:21 AM, Stephan Beal  wrote:

> IIRC we don't actually use the mtime in the config file (or not often,
> anyway). Feel free to set it to 0 or (as we do internally):
> strftime('%s','now'). It's a Unix timestamp (so (date +%s) can be used from
> scripts).
>
>
Forgot to comment on *this*. Thanks for the strftime('%s','now'). I'll just
use that. Certainly something I could have learned from perusing source
code, but the rest of the stuff seemed to complicate the question enough to
make it worth asking on list.

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] Automation

[Scott Robison]

On May 9, 2014 3:11 AM, "Stephan Beal"  wrote:
>
> On Fri, May 9, 2014 at 9:50 AM, Scott Robison 
wrote:
> It doesn't need to be great - it'll just be for my own use. i've never
gotten around to using the "login group" support.

I looked briefly into it and it seemed that the shared login group stuff
only allowed read access to subordinant repos, so I just decided to build a
very basic solution that met my modest needs. :)

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] Location of ".fossil" Database

[Scott Robison]

On May 21, 2014 9:34 AM, "Igor de Oliveira Couto" 
wrote:
>
> Dear Fossil Gurus,
>
> I'm a new user - have been using Fossil for just over a month now - and
I'm loving it. One point that I found somewhat disappointing, is that
Fossil creates a ".fossil" database in my home directory.
>
> I know that many applications in Linux/Unix store their preferences and
settings in dot-files, in the user's home directory - ie., "~/.myapp".
This, however, is a Linux standard, and does not translate to other
platforms.

I see many other people have commented already, but in reading the thread
there was one point I never saw raised.

In the Mac OS (pre OSX) you pretty much had to write apps specifically for
a Mac. OSX however is really two different systems in one: the native Mac
system with lots of guidelines om how things are to be done, and a fairly
standard POSIX platform underneath that can run a huge number of programs
without modification. In this world, fossil is just another app using the
posix layer, behaving just as any other similar app would behave.

It is a shame that Windows doesn't natively support something similar out
of the box, but it's origins and life cycle have *never* coincided with
posix. Even so, you don't have to write full blown gui apps on Windows, you
just have to use a different API if you want to support console mode. And
if you want to support Windows, you either do that or require your app to
be built with something like cygwin (which many posix apps do require).

OSX however "threw away" the older Mac history when it decided to go the
route of an open source kernel with proprietary stuff on top.

In any case, while I can see why one would want a program to give their
native platfom more attention, in this case fossil is really just a posix
app that can be built like almost any other and run on OSX because it
supports those types of apps.

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] Location of ".fossil" Database

[Scott Robison]

BAH! How dare someone make my wordy points while I'm also making them! :)

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] Location of ".fossil" Database

[Scott Robison]

On Wed, May 21, 2014 at 12:02 PM, Stephan Beal wrote:

> i will most certainly attempt to remember that point the next time this
> comes up. It reduces the argument form "Mac vs Windows vs *nix" to "POSIX
> vs non-POSIX," which is not only simpler to grasp and argue around, but is
> geeky enough to scare away casual listeners ;).
>
> For those who don't know, POSIX == Portable Operating System Interface, a
> series of standards which specify APIs for various system-level services.
> _Some_ APIs are specified by the core C specifications (fossil only
> explicitly relies on C89), but POSIX basically starts off at the points
> where C leaves the details platform-defined. As Scott points out, MS has
> had a not-very-POSIX-friendly past:
>

And to some extent, why should it (have a friendly POSIX history)? Mac OS
(pre OS-X) had just as bad (I would say worse, actually) POSIX history. The
first POSIX standard was released in 1988, and the standardization efforts
began around 1985 (according to the Wikipedia article). Both Windows & Mac
OS pre-date POSIX. Prior to that, there were as many operating system
standards as there were brands and models of computers (or very nearly so).
1988 was the first time there existed an actual standard for a minimum set
of interfaces that could be used "portably" between different systems that
adhered to the standard. Even then, it is a *minimum* set of standards that
a portable application could be written to target, but it is not a maximum
set of interfaces.

I would say that MSDOS came "closer" to supporting something that could be
called Linux out of the box than Mac OS 9 & earlier ever did. It was still
a million miles away, so closer isn't saying much, but closer nonetheless,
since it actually supported something resembling a terminal window and
command line interface and command line oriented tools and Mac OS did not
"out of the box". OS-X was a brilliant move for them to make (which of
course evolved from Apple's acquisition of Next and it's intellectual
property). Use that, add shims to provide for backward compatibility (much
as they did when they migrated from Motorola 68000 series chips to PowerPC
chips), and viola! Something all your fans like that provides the power to
move forward.

Many people rail on Microsoft & modern Windows for not being POSIX
compliant, but really, what is the motivation? Early NT versions (early to
mid 90s) *did* advertise POSIX compliance, though I don't think it ever
shipped with the base system. At least not completely. There are system
level APIs needed for POSIX, but there is also a whole host of userland
utilities that must work a particular way to be truly POSIX. You could buy
or download from Microsoft a bundle of software to bring it up to a full
POSIX system if you wanted, but the history just wasn't there. All non-NT
versions of Windows were effectively little more than an Xwindow server
with a different API that ran on top of DOS. Because of the history, NT
versions of Windows provided something that more closely resembled DOS than
POSIX, while providing APIs for POSIX and OS/2 compatibility along side the
"native" NT/Win32 APIs.

Unix / POSIX has pretty successfully taken over the world of operating
systems from virtually all other contenders (Amiga, BeOS, Commodore Kernal,
etc, ad nauseum), with the single exception of Windows. Given the origins
of Windows as a layer on top of DOS which was basically a CP/M knock off
(which is fine, since Linux is really just a Unix knock off), it makes
perfect sense why Microsoft doesn't feel the need to natively support
POSIX. Mac OS-X supports it, but it would be disingenuous to say they
advocate writing POSIX software; they want the whole world to be Mac
centric. They just get POSIX support for free so they don't actively
disable it. Yet. I say just give them time. ;)

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

[fossil-users] users table photo column

[Scott Robison]

You may remember reading a few weeks back I've been playing around with
putting together some "management" web management scaffolding around my
repos to automate certain things (like copying "shared settings" from one
repo to another, because I'm OCD like that, and not all config appear to
have "global" versions).

In any case, in the process I was looking at schema and saw there is a
"photo" column in the users table. I imagine it is for a photo of the user,
but cannot find anywhere that it is used. Is this something that was added
for specific skins/themes to use or is it something that is generally
usable/accessible?

This is mostly a curiosity based question. At the moment all the photo for
all rows is NULL so it's not something I'm "worried" about copying, per se.
Just wondering the rationale/workings of 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] users table photo column

[Scott Robison]

On Tue, May 27, 2014 at 4:22 AM, Richard Hipp  wrote:

> In any case, in the process I was looking at schema and saw there is a
>> "photo" column in the users table. I imagine it is for a photo of the user,
>> but cannot find anywhere that it is used. Is this something that was added
>> for specific skins/themes to use or is it something that is generally
>> usable/accessible?
>>
>
> Originally designed for a photo of the user, but not currently used.
>

Thanks. BTW, for those who might be curious, it is a pain to get php &
fossil to cooperate to create a new repo (HOME env var needs to be set and
user can't be detected so --admin-user must be specified). I think it was
mostly due to the late hour, as the php system function doesn't display
stderr by default, and it took me a while to realize I needed to redirect
it myself so I could read the useful command line errors fossil was
*trying* to display. Once I did that, it was trivial to get everything
working.

Probably shouldn't work so late. Whatever. My stuff is now working.
YAY! Sorry for polluting the mail list with my self congratulatory blather.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Markdown

[Scott Robison]

Is there a "definitive list" of what is and is not supported by the
markdown engine within fossil WRT repo relative links? Other than reading
the code, that is? The best I can come up with for a link to a wiki page
(from another wiki page) is something like "[Page](wiki?name=Page)" which
really seems kinda ugly (though I like the rest of what little I've played
with so far).

-- 
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] Markdown

[Scott Robison]

On Wed, May 28, 2014 at 12:05 PM, Warren Young  wrote:

> On 5/27/2014 22:58, Scott Robison wrote:
>
>> The best I can come up with for a link to a
>> wiki page (from another wiki page) is something like
>> "[Page](wiki?name=Page)" which really seems kinda ugly
>>
>
> You probably want this syntax:
>
> [Page][1]
>
>
> later, typically at end of doc...
>
> [1]: wiki?name=Page
>

Thanks. I did realize I could use [Page](wiki/Page) which is better if I
just want to do it inline. The footnote style is good to know as well.

Still, I've read various things online about "what markdown does fossil
support" and I've read something like "vanilla markdown plus some form
tables extension". It would be nice to have a very central place (like a
wiki page on the fossil repo) that says "Here is the definitive list of
what markdown use can use on fossil". I'm beginning to think the only place
that documentation exists is in the code (which is fine, no one owes me an
explanation for free software). Is this the 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

Re: [fossil-users] Markdown

[Scott Robison]

On May 28, 2014 2:31 PM, "Warren Young"  wrote:
>{deleted stuff}
> The attached Fossil repo also contains a copy of the official Markdown
documentation.  It was included in the test suite, so I linked to it from
the repo's wiki, rather than remove it.
>

Thanks very much for the effort!
___
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] DRH's PGCon 2014 Keynote (with Fossil sighting!)

[Scott Robison]

On Sun, Jun 1, 2014 at 5:20 PM, Joel Bruick  wrote:

> I just wanted to share Richard's PGCon 2014 keynote for anyone here that
> wasn't aware of it:
>

Thanks for sharing that. And it was good to hear an entire presentation
about SQL without once (that I can recall) hearing it pronounced "sequel".
:)
___
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] DRH's PGCon 2014 Keynote (with Fossil sighting!)

[Scott Robison]

DOH! Ah well, usually it was S-Q-L. :)
On Jun 2, 2014 10:00 AM, "Stephan Beal"  wrote:

> On Mon, Jun 2, 2014 at 5:10 AM, Scott Robison 
> wrote:
>
>> Thanks for sharing that. And it was good to hear an entire presentation
>> about SQL without once (that I can recall) hearing it pronounced "sequel".
>> :)
>>
>
> Sorry, Scott: @ 4:41s
>
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> 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] Bookmarks (Re: git->fossil->git does not obtain the same commit hashes.)

[Scott Robison]

On Wed, Jun 4, 2014 at 12:56 PM, Joel Bruick  wrote:

>
> I think Git is a great, powerful, and flexible tool that actually has a
> much simpler design than it initially appears. But to get to a place where
> you actually understand that design (and, thus, understand Git), takes
> about 99x more effort than 99% of the software I've ever used.
>
> Once you get to that point, though, it's wonderful! ;)
>

I really want to steal this in tweet form:

"To get to a place where you understand Git's design takes 99x more effort
than 99% of software. Once you get to that point it's wonderful!"

Would you mind? :)
___
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] Bookmarks (Re: git->fossil->git does not obtain the same commit hashes.)

[Scott Robison]

On Wed, Jun 4, 2014 at 1:29 PM, Joel Bruick  wrote:

> Consider it yours.
>

Thanks. Final form:

OH: To understand Git's design takes 99x more effort than 99% of software.
Once you get to that point it's wonderful! // Too true!

Curse the 140 character limit! :)

-- 
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] Bookmarks (Re: git->fossil->git does not obtain the same commit hashes.)

[Scott Robison]

On Wed, Jun 4, 2014 at 1:56 PM, Richard Hipp  wrote:

> On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison 
> wrote:
>
>> I really want to steal this in tweet form:
>>
>> "To get to a place where you understand Git's design takes 99x more
>> effort than 99% of software. Once you get to that point it's wonderful!"
>>
>>
> Does that quote belong on this page:
> http://www.fossil-scm.org/fossil/doc/tip/www/quotes.wiki
>

The full original definitely belongs there:

I think Git is a great, powerful, and flexible tool that actually has a
much simpler design than it initially appears. But to get to a place where
you actually understand that design (and, thus, understand Git), takes
about 99x more effort than 99% of the software I've ever used.

Once you get to that point, though, it's wonderful! ;)

Attributed to Joel Bruick. :)


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

[fossil-users] Links within Fossil

[Scott Robison]

I don't think this is currently possible, but I've been wrong before, so
let me ask: I know it is possible to link to individual artifacts by ID
which displays the source, but is it possible to link to a given line
number (range) within a given artifact, perhaps highlighting it in the
process?

My reason for asking: I've been given a new assignment by my employer to
learn / understand some relatively obscure source code written by a former
employee. This is proprietary code that can't be shared outside the
company, but it is not documented (by which I mean there are comments
through the code, but no real design or high level understanding of *why*
it does *what* it does).

My thoughts on how to handle this task (where code is currently stored in
an svn repo and will be migrated in the not too distant future to git) is
to take the current code and import it into a fossil repo, then use the
wiki / inline documentation features to describe it in detail. Part of what
I would like to do in the documentation is link to individual lines or
blocks in the individual source files so that the reference is internally
complete so that I don't have to keep separate source & documentation files
in sync.

Thanks in advance for your help!

-- 
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] Links within Fossil

[Scott Robison]

On Jun 6, 2014 4:20 PM, "Richard Hipp"  wrote:
>
> On Fri, Jun 6, 2014 at 6:12 PM, Scott Robison 
wrote:
>>
>> ... is it possible to link to a given line number (range) within a given
artifact, perhaps highlighting it in the process?
>
> You mean like this:
http://www.fossil-scm.org/fossil/artifact/6eb26bb7a6?ln=1755-1759

[Snipped]

Thank you so much, that's exactly 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] autosync from GUI

[Scott Robison]

On Jun 7, 2014 1:27 PM, "Ron Wilson"  wrote:
>
> On Sat, Jun 7, 2014 at 2:23 PM, Stephan Beal 
wrote:
>>
>> For the local UI case, sure, i can see it being useful, but people would
also expect it to work remotely, and it often wouldn't.
>
> When running the local UI, that is seen as part of the local client, but
when accessing a remote server the perception is different. I think it
reasonable that the "server Fossil" not try to autosync to another server
Fossil.

Please forgive what may be a stupid observation, but if there are users
that need ticket or wiki access (workflows that are typically ui only),
might not the best approach be to give them appropriate access to the
master via http (as someone already says they do indirectly by making that
the master copy)?

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] autocrlf like in Git?

[Scott Robison]

On Jun 7, 2014 1:47 PM,  wrote:
>
> Well, I can give a couple of personal examples that you easily try
yourselves:
>
> * Windows side: Copy/Paste in Windows can not deal with LF endings
correctly.  Example: PNotepad editor in Windows loads Linux files but
copy-pasting from it (for example) to other apps messes up all text (puts
it all in a single line).

Yes, though this is more a deficiency with a particular program than with
Windows at large. The fact is that the convention of "newline only as EOL
marker" is just a convention. CRLF is arguably more correct, particularly
given the era in which it was established.

> * Linux side (vi): Have you tried editing a Windows text file under vi?
It shows all ^M (CRs) at the end of each line.

I have, and agree it is annoying, but that is an issue of vi choosing not
to handle alien text file formats.

> * Several old time assemblers will choke on wrong line endings.  Their
binaries cannot be updated as the source is no longer available.  So, you
must edit code only in the right format or you’re out of luck.

This seems to be conflating the editing of assembly source with editing of
binaries for which source is no longer available. What am I missing?

> I also wrongly assumed the guys who maintain Git saw a reason for having
this option.  I can promise you it wasn’t me who asked for it, so they must
have had nothing better to do than to add a useless feature in their app
that nobody ever needs.

Now this is maybe a slightly emotional response. No one has told you EOL
conversion is a useless feature, just that in their opinion that it doesn't
belong in a particular DVCS whose primary overriding concern is "store what
I tell you to store exactly as I have stored it". To me this makes sense,
particularly on a platform (unixen) that is notorious (to a fault maybe?)
of advocating tools do one thing and do it well.

I agree that there are tools that will "do the wrong thing" with mixed or
alien EOL markers. My bread and butter is provided primarily by Windows
development, so I have to use Visual Studio extensively. It detects mixed
line endings on open and offers to normalize. Perhaps an email to vi or
emacs or [insert editor of choice] devs might convince them to change their
tools. :)

I think one of two potential solutions are possible here though:

1. Convince the devs to support hooks (which have their own issues as
argued in the past), particularly pre/post commit and post update hooks. In
this way tooling (such as tr or dos2unix/unix2dos) could be made to
normalize line endings after changes.

2. In the absence of hooks, relatively simple shell scripts could do the
exact same thing.

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] autocrlf like in Git?

[Scott Robison]

On Jun 7, 2014 12:44 PM, "Richard Hipp"  wrote:
>
> Years ago (decades ago, actually), somebody rigged up fopen() so that it
did automatic NL <-> CRNL conversions unless you used "rb" or "wb" as the
"type" parameter.  This seemed like a clever solution at the time and was
warmly embraced by many developers.
>
> However, with the passage of time, this auto-convert-by-fopen idea was
found to be a misfeature.  An anti-pattern.  It lead to a lot of bugs, and
a lot of work-around code.  It sometimes converts when you do not want it
to.  It sometimes fails to convert when you do want it to.  It is a general
nuisance and pain.

I would disagree to this extent: misuse of this feature is a problem, and
by extension ignorance of it is a problem (by which I mean those unfamiliar
with it,  not that you are ignorant of it). It is a platform / portability
concern feature, in that if you take pure C run time library based code
that uses the C platform standard of newline for EOL markers, you can
recompile it without modification and get a program that does the right
thing for whatever system (newline on unixen, CRLF for DOS & Windows, CR
only on classic Mac systems). They will generate text that can easily be
consumed on the platform and will be able to consume text created by other
programs that follow the platform's standard EOL convention.

I don't agree that the presence of the feature is a problem. If you meant
that the way it was implemented (an optional modification to a parameter to
fopen) is the misfeature, then I can agree that it would have been better
to do it some other way with 20/20 hindsight, but it was a reasonable
solution based on existing practice and "standardization" efforts of the
70s & 80s.

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] autocrlf like in Git?

[Scott Robison]

On Sat, Jun 7, 2014 at 3:40 PM,  wrote:

> * Several old time assemblers will choke on wrong line endings.  Their
>>> binaries cannot be updated as the source is no longer available.  So, you
>>> must edit code only in the right format or you’re out of luck.
>>>
>>
>  This seems to be conflating the editing of assembly source with editing
>> of binaries for which source is no longer available. What am I missing?
>>
>
> What is not clear?  Old assembly source may still be updated, as needed,
> to support existing products.  But the assembler used to convert this
> source to binary cannot itself be updated as its source is no longer
> available, only the binary survives.  The assembly source is written for
> this assembler so you’re stuck using it.  For old projects that will
> eventually die, it's not worth the effort creating a newer (better
> behaving) assembler, and possibly converting all target source code to a
> possibly incompatible new assembler's syntax introducing a whole bunch of
> new problems.


AH! That is what was not clear to me, and hence why I asked. You meant the
assembler's source code was no longer available to edit, when I thought you
meant the assembler's output was not editable. But in this case if you have
the source for the program you want to assemble, and an assembler that only
understands a single EOL marker, you can modify the EOL markers of your
source via tr or dos2unix/unix2dos.


> Now this is maybe a slightly emotional response. No one has told you EOL
>> conversion is a useless feature, just that in their opinion that it doesn't
>> belong in a particular DVCS whose primary overriding concern is "store what
>> I tell you to store exactly as I have stored it". To me this makes sense,
>> particularly on a platform (unixen) that is notorious (to a fault maybe?)
>> of advocating tools do one thing and do it well.
>>
>
> In general, an SCM that is supposed to be used by various people each
> working on a their own ‘random’ platform should be able to give to all of
> them the impression that text files are normal text files, that is ‘normal’
> according to their own system, not to the system of the person who
> initiated the repo.  Otherwise, repos should be marked as ‘Linux-only’,
> ‘Windows-only’, ‘Mac-only’, etc.  and trying to open them in the wrong
> platform should fail with a related error message. Do we agree so far?  If
> not, there is no need to read further.
>
> Given that all text files contain their meaningful info in the part of the
> file that is not the EOL marker, and the EOL marker is only there to assist
> the underlying OS/library to be able to correctly load/process that text
> file, changing those EOL at will to be compatible with the user’s current
> platform is not a violation of any sanctity.  If the platform’s tool cannot
> deal with a text file in its own native format, then that tool is at fault,
> nobody else.  But if a tool cannot deal with a text file of a different
> platform, we cannot blame the tool.
>
> Finally, regarding a comment in another response about the complexity of
> this change, as for the hash values computation, a stream can easily be
> wrapped inside another routine that produces a normalized stream that is
> then fed into the hash calculator.  I really do not see the complexity.
> Maybe I don't have enough decades in this job yet, who knows?
>

I completely agree with the points other than the one that "the DVCS is the
only tool that can effectively manage the EOL convention of the files". I
use a text editor daily that is capable of normalizing EOL convention
(though of course there are few things capable of starting a flame war as
effectively as suggesting to any random group of people that their OS or
text editor is inadequate to some task). :)

As long as we're talking about features we'd like to see in a swiss army
knife DVCS: a lot of time is spent telling people what the coding standards
are for an individual project, things that make EOL conventions seem minor
(but would certainly include such things). I'm surprised no one has grafted
onto git (or some other DVCS, or maybe I'm just not aware of the one that
does) an ability to reformat all source code to match the standards of the
project before committing it to the repository. Plenty of programs exist to
reformat source code (at least for C & C++), and wouldn't it be awesome if
we could always check out code formatted to our own preferences and always
make sure that no matter what our preferences were out commits always
matched the project standards?

Hey, DRH, get right on this, will ya? ;)

Also, I dislike editing Ruby. I need a DVCS that will convert it to Python
automatically for me and then reverse that when I commit. :)

Yes, I'm being ridiculous, and I apology. It's more because I found these
last two thoughts amusing (particularly the last). I can see a use for
tools / hooks that can do this. I don't always agree with DRH, and admit
that I liked the idea of the s

Re: [fossil-users] autocrlf like in Git?

[Scott Robison]

On Sat, Jun 7, 2014 at 4:08 PM,  wrote:

>> I completely agree with the points other than the one that "the DVCS
> is the only tool that can effectively manage the EOL convention of the
> files". I use a text editor daily that is capable of normalizing EOL
> convention (though of course there are few things capable of starting a
> flame war as effectively as suggesting to any random group of people that
> their OS or text editor is inadequate to some task). :)
>
> I didn’t say that (“..only tool..”).  But, using tools is all about
> convenience.  Yes, we can use Python, Lua, or whatever other scripts to do
> whatever work isn’t done automatically.  But, this loses on convenience.  I
> could also keep (as I did until I started using FOSSIL) all my older
> versions in dated RAR files, and go back to any version I want to.  But, at
> what cost in terms of convenience?
>

Fair enough. I like fossil because of the convenience of having the wiki &
ticket systems integrated into the single file repository. I dislike git
because of the inconvenience of needing to earn a post graduate degree to
understand it. ;) Again, it doesn't seem overly inconvenient to add a
little scripting, but agree that it is "less convenient".


> > But I can also see the point to the idea that "this is the file I
> created and this is exactly what I want to see when I pull it out of a repo
> that I put it into".
>
> And that’s why those things should always be optional.  I never said it
> should be imposed on everyone just because some like it this way.  But not
> having the option is akin to the other side imposing their ‘right’ way on
> everybody else.
>

Flexibility is a nice thing, I agree. I suspect that's why the CRNL glob
was put in, to give flexibility to people who didn't want to see warnings
because their platform didn't conform to the unixen EOL standard. Or that
so much effort is spent to make fossil portable between Windows and posix
platforms, or why there is a built in web based GUI interface where other
tools would tell you to just use the command line & terminal mode. There
are ideological differences between git and fossil. It's why Linus created
git as he felt the existing tools were inadequate for various reasons (be
they centralized in the case of svn or pricey in the case of bitkeeper).
It's why DRH created fossil, who wanted immutable history vs rewritten
history, among other things.

All software is going to tell you there is a right way to do certain
things. git vs fossil, vi vs emacs, Windows vs unixen, c++ compilers vs
python interpreters.

In any case, my offer still stands to help script a solution that'll give
you what you need! I'm by no means a fossil expert, but I'm confident I
could help with something like this if you needed it.

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