On 4/11/2017 3:24 PM, Thomas wrote:
On 2017-04-11 23:09, Ross Berteig wrote:
On 4/10/2017 11:48 AM, Thomas wrote:
Actually, I got a batch file that reads the file filter settings from
another file and creates the binary-glob and the ignore-glob files on
the fly before an addremove and a commit (crlf-glob is not created and
only contains an asterisk now).
Why do this on every commit?
That's a legit question. The reason is that at first I only learned
about the command line swiches, that take the list comma separated.
My files however contained a mask on each line, basically the same way
the .fossil-settings files are outlined. I only learned about the
.fossil-settings folder later here in the mailing list, hence I just
quickly changed the batch file to create the required files.
The reason why I had my files in this format is because I assembled my
lists from sources on the web with common file name extensions, file
and folder names.
The whole point of the versioned settings is that they can be set once
and stored, and are carried with the repository into every working
folder on fossil open.
The only differences to my file is that it's got a different filename
extension for which Notepad++ allows me to insert syntax-highlighted
coments, and that it sorts the list. That's all.
You figure out what files never need saving, and put globs in
ignore-glob that match them. Note that the globs are matched on the
whole pathname in the working folder, so you can exclude entire folders
too if that is handy. Which is nice for things like the Release and
Debug folders that VS tends to create in its projects. You will want to
work out carefully what files your IDE needs to be treated like source
code, which of those are binary (a stupid mistake made by too many IDEs
is to use binary files for project configuration which makes using
version control harder than necessary), and which files are build
products.
Something like this is my usual starting point for ignore-glob for a lot
of projects. I usually create ignore-glob right after creating the
repository and before checking things in. I always include globs for
whatever backup files get created by my text editors, all the build
products I can identify, and if practical, any folders created by
building.
~*,*.bak
*.o,*.d
*.obj,*.exe,*.dll
*.bin,*.hex
*Build*/*
*build*/*
ship/*
*.zip,*.tar*
The fossil extras command is useful for finding things that belong in
ignore-glob. It lists the files that fossil addremove would add or
fossil clean would delete.
IDEs come with an extra burden. They always seem to be written by people
that believe there is no world outside of the IDE, and especially no
version control. Worse, they also seem to be hostile to all the other
IDE developers, and highly resistant to any sort of standardized naming
of things. On the positive side, there is this project at Github where
people are tracking what to tell Git to ignore. The syntax isn't
identical for fossil, but the data is still valuable.
https://github.com/github/gitignore
This is actually one of the sources I based my exclusion list on.
I added other files too. I replaced all # characters at the beginning
of each line with semicolons, extracted the files like [Tt]umbs.db to
Thumbs.db and thumbs.db, saved it, and let my batch file create a
comma-separated list for the --ignore command line switch.
My key point here is that this is a one-time setup for a repository.
Possibly a second time when you discover something you missed, or add a
new tool to the project. Not something you should need to edit constantly.
I've been using fossil for years with projects in C and Lua, for many
different target architectures, with and without several IDEs, and even
for documentation-only projects with text in Markdown or LaTeX where
builds produce PDFs.
I essentially never use fossil addremove. It is not part of my workflow
at all.
I do use fossil extras and fossil changed as part of my habitual review
before I commit changes. The extras command tells me if I forgot about a
new file. The changes command tells me what files I actually changed. In
both cases, I want to know that I'm not committing large swaths of
unexpected files.
To my mind, addremove is simply too powerful since it assumes that
missing and new files are intentionally missing and new. That means that
fossil addremove will also mis-handle a renamed file, which would
otherwise be correctly handled by using fossil mv to tell fossil the
file changed names.
I actually almost never use fossil clean for much the same reason: it is
too powerful, I don't want it breaking my IDE just because after a tool
upgrade it suddenly is writing some new intermediate file I hadn't yet
heard of.
I tune the ignore-glob based on what fossil extras is saying, generally
aiming for extras to be an empty list.
I always use .fossil-settings for complex settings like the various
globs. It is too hard to get the command line right, and although UI can
change them safely, they are not versioned and so won't get updated to
track changes in the development.
IMHO, you are overthinking things a little here. Let fossil manage what
it manages, and use the ignore feature to guide it gently.
In any case, you don't generally want to do addremove and commit in a
single operation because that doesn't give you a chance to review (and
test) what it decided to add and remove before it is committed to
immutable history.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
