For me tickets are ok and by default you have type 'Task' configured.
If you create a report that filters by this, isn't it enough?
Regards,
Jacek
2010/2/10 Ron Aaron r...@ronware.org
Concerning ticket [2b79f36e5a], I agree with the notion. However, I would
take it a bit further and
Problem
I forget to add in new files that I create. This leads to me creating
one or more check-ins that aren't a complete representation of the
working set of files. Worse, the new files are often the ones that I'm
working on most actively because they're new.
Suggestion
If before a checkin you just recursively add everything fossil very nicely
doesn't add things in twice. I.e. if it's already in the repository it doesn't
put it in again. The new stuff will be added and your problem is handled. The
only problem is adding in files you don't want in the repo
What I could really, really use is a way to persistently ignore files
and entire directories. It's great to keep all your files that shouldn't
be version controlled out of your project dir, but I'm working on
someone else's existing website (converted from CVS to fossil, thanks to
a handy script
Hello,
What about?
fossil ignore file1 file2 ...
In this case, fossil would store the names of the files in the
repository. These files would not appear in fossil extras and
would give an error if fossil add
fossil ignore directory1 ... directory2 ...
the same, but would apply to all
I was looking to have a ticket report that was ordered by status, but with an
arbitrary ordering of the status groups (Open, then Fixed, then Deferred,
then ...). No problem I'll just use SQLite CLI to create my own enum table
with the statuses, and a display order for each, then join ticket
Hi,
It seems --date-override doesn't work correctly with fossil new, which
is required for importing files from other repositories:
$ fossil new test.fsl -A test --date-override 2010-01-01 UTC
project-id: 05468b497577aa00211a76732a997723fb5a8acf
server-id:
7 matches
Mail list logo
