On Apr 20, 2015, at 4:20 PM, Kevin Youren <kyou...@gmail.com> wrote:
>
> I'll investigate the "embedded" and SVG links more deeply.
Also look into Markdown. You may find, as I have, that word processors occupy
a shrinking niche.
Most people use word processors either as glorified typewriters or as
dumbed-down page layout systems. Page layout software has gotten nearly as
easy to use as a word processor, and text-based document systems (MD, HTML,
wiki, LaTeX…) have gotten powerful enough to displace most other uses of word
processors.
> Hence the superiority of Fossil with a Wiki versus GIT without. My guess
> is GIT will catch up.
GitLab is kinda-sorta like Fossil.
To me, the argument for Git comes purely down to integration and power.
1. Do you need to use the repo from some other tool that doesn’t speak Fossil
but does speak Git?
For instance, if you’re the sort who insists that you can only use Visual
Studio and you can’t leave the environment ever for any reason at all
whatsoever, then you’ll want to use its built-in Git support instead of Fossil.
2. Do you have Linus Torvalds class software configuration management problems?
Yes? Then you might actually require Git instead of Fossil.
For the vast majority of software projects, Fossil is perfectly capable, and a
whole lot easier to use than Git.
If the above has made you think that maybe you should start with Git *just in
case*, then I’ll point out that Fossil has a built-in Git export facility.
Start with Fossil, then use it until it fails you. Then decide if Git would
have saved you from that particular problem.
(And then if you find yourself on the edge, factor in all the *other* problems
you’d buy by with that switch to Git. No VCS is perfect. Choose the one that
offers you the smallest bag of problems for your particular use case set.)
> The Wishlist concept looks interesting and appealing.
I didn’t invent it. I only saw a good thing and adopted it.
In so many other projects I see, someone will come up with a good idea,
everyone will agree that it’s a good idea, and no one will have time to do it
right at that moment, so it gets forgotten.
I’ll be the first to admit that Wishlists have a way of just growing without
limit, but at least you have a place to go look if you’re thinking of adding a
feature, or just bored. You may find that part of the design work has already
been done for you.
You can “garden” a Wishlist to turn it into a more serious sort of design doc
instead of a dumping ground by breaking it up into sections, as Markdown allows:
Wishlist, v4.0
---
Bug Fixes, Any Version
===
- The foobie button sometimes crashes the app when the
framnitz field has too much text in it.
To-Do, This Version
====
- Item 1
- Sub-item 1
- Sub-item 2
- Item 2
Tentative v5 Plan
====
- Wowee feature 1
- Wowee feature 2
Then when it comes time to start the v5 development effort, you promote any
remaining items in the bug fix and and v4 feature sections as to-do for v5.
Presumably you also create a v4 “stable” branch at this point, in which the
Wishlist should be probably emptied, if you’re the sort of development
organization that does all new development on the trunk, with occasional
backports to stable branches.
This may look a lot like some other software development processes you have
heard about. Just add some voting and such, and you have user stories from
some flavors of Agile, for example.
> My overall "want" is to move errors, failures, oopsies, etc out of
> "production execution" back toward the beginning of the Software
> Development Life Cycle. From Code back to Design and Testing design.
If you’re using Fossil’s ticketing system, you can link to tickets from wiki
pages, embedded docs, etc.
http://fossil-scm.org/index.html/doc/trunk/www/tickets.wiki
> They use Microsoft
> Word, Excel and Powerpoint docos in the hundreds and mega numbers of
> emails. So, communicating, storing and tracking what people "want" is
> reasonably important.
Well, I don’t suppose I need to tell you about the problems you get when design
docs are tied up in proprietary document formats.
Just a week or so ago, someone told me about a standard practice at his
previous company to write everything up in Word and attach all associated
collateral materials to the doc itself. (Apparently Word has an email-like
attachments system. Who knew?) Then they just email the Word document ‘round
and ‘round the organization.
The idea being, that no one can claim that they didn’t get all the pieces.
:shakes head:
I will warn you that if you try to treat Fossil like a SharePoint wannabe,
you’re going to end up disappointed. It is not for storing massive numbers of
frequently-changing BLOBs.
(Git isn’t particularly good at it, either, by the way.)
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
