|
1
|
<title>Reviews</title> |
|
2
|
<b>External links:</b> |
|
3
|
|
|
4
|
* [https://www.nixtu.info/2010/03/fossil-dvcs-on-go-first-impressions.html | |
|
5
|
Fossil DVCS on the Go - First Impressions] |
|
6
|
|
|
7
|
<b>See Also:</b> |
|
8
|
|
|
9
|
* [./quotes.wiki | Short Quotes on Fossil, Git, And DVCSes] |
|
10
|
|
|
11
|
<b>Daniel writes on 2009-01-06:</b> |
|
12
|
|
|
13
|
<div class="indent"> |
|
14
|
The reasons I use fossil are that it's the only version control I |
|
15
|
have found that I can get working through the VERY annoying MS |
|
16
|
firewalls at work.. (albeit through an ntlm proxy) and I just love |
|
17
|
single .exe applications! |
|
18
|
</div> |
|
19
|
|
|
20
|
|
|
21
|
<b>Joshua Paine on 2010-10-22:</b> |
|
22
|
|
|
23
|
<div class="indent"> |
|
24
|
With one of my several hats on, I'm in a small team using git. Another |
|
25
|
team member just checked some stuff into trunk that should have been on |
|
26
|
a branch. Nothing else had happened since, so in fossil I would have |
|
27
|
just edited that commit and put it on a new branch. In git that can't |
|
28
|
actually be done without danger once other people have pulled, so I had |
|
29
|
to create a new commit rolling back the changes, then branch and cherry |
|
30
|
pick the earlier changes, then figure out how to make my new branch |
|
31
|
shared instead of private. Just want to say thanks for fossil making my |
|
32
|
life easier on most of my projects, and being able to move commits to |
|
33
|
another branch after the fact and shared-by-default branches are good |
|
34
|
features. Also not having a misanthropic command line interface. |
|
35
|
</div> |
|
36
|
|
|
37
|
<b>Stephan Beal writes on 2009-01-11:</b> |
|
38
|
|
|
39
|
<div class="indent"> |
|
40
|
Sometime in late 2007 I came across a link to fossil on <a |
|
41
|
href="https://sqlite.org/">sqlite.org</a>. It was a good thing I |
|
42
|
bookmarked it, because I was never able to find the link again (it |
|
43
|
might have been in a bug report or something). The reasons I first |
|
44
|
took a close look at it were (A) it stemmed from the sqlite project, |
|
45
|
which I've held in high regards for years (e.g. I wrote bindings for |
|
46
|
it for Mozilla's SpiderMonkey JavaScript engine), and (B) it could run |
|
47
|
as a CGI. That second point might seem a bit archaic, but in practice |
|
48
|
CGI is the only way most hosted sites can set up a shared source |
|
49
|
repository with multiple user IDs. (i'm not about to give out my only |
|
50
|
account password or SSH key for my hosted sites, no matter how much I |
|
51
|
trust the other developers, and none of my hosters allow me to run |
|
52
|
standalone servers or add Apache modules.) |
|
53
|
|
|
54
|
So I tried it out. The thing which bugged me most about it was having |
|
55
|
to type "commit" or "com" instead of "ci" for checking in (as is |
|
56
|
custom in all other systems I've used), despite the fact that fossil |
|
57
|
uses "ci" as a filter in things like the timeline view. Looking back |
|
58
|
now, I have used fossil for about about 95% of my work in the past |
|
59
|
year, in over 15 source trees, and I now get tripped up when I have to |
|
60
|
use svn or cvs. |
|
61
|
|
|
62
|
So, having got over typing "fossil com -m ...", here's why I love it so much... |
|
63
|
|
|
64
|
Point #1: CGI |
|
65
|
|
|
66
|
Again, this sounds archaic, but fossil has allowed me to share source |
|
67
|
trees which I cannot justifiably host in other projects I work on |
|
68
|
(they don't belong to those projects), which I cannot host in google |
|
69
|
code (because google code doesn't allow/recognize Public Domain as a |
|
70
|
license, and I refuse to relicense just to accommodate them), and for |
|
71
|
which SourceForge is overkill (and way too slow). With fossil I can |
|
72
|
create a new repo, have it installed on my hoster |
|
73
|
(https://fossil.wanderinghorse.net), and be commiting code to it within |
|
74
|
5 minutes. |
|
75
|
|
|
76
|
Point #2: Wiki |
|
77
|
|
|
78
|
I hate wikis. I really do. Always have. They all have a different |
|
79
|
syntax and the content tends to get really disorganized really |
|
80
|
quickly. Their nature makes it difficult to reorganize them without |
|
81
|
replacing old pages with lots of "has been moved to |
|
82
|
<nowiki>[TheNewPage]</nowiki>" |
|
83
|
links. I'm one of those "code for tomorrow" coders (i.e., code such |
|
84
|
that it'll be easy to reorganize/refactor later). I like to document |
|
85
|
the same way, and wikis make that problematic. Then again, no |
|
86
|
documentation system is really good in that regard. |
|
87
|
|
|
88
|
That said, fossil has made me love having a centralized, common |
|
89
|
documentation platform. Whereas I used to document everything in the |
|
90
|
API docs (header files) and often include an ODT file for a library |
|
91
|
manual, fossil has become my preferred platform for non-API |
|
92
|
documentation because it's just so easy to do. No matter where I am, I |
|
93
|
can log in and write (I write a lot). The added ability to export my |
|
94
|
wiki pages, edit them in xemacs, and re-import them just makes it |
|
95
|
nicer, as I can tweak as much as I want without ending up with 10 |
|
96
|
"updated wiki page SoAndSo" messages in the commit log. |
|
97
|
|
|
98
|
|
|
99
|
Point #3: running a server locally |
|
100
|
|
|
101
|
Fossil runs not only as a CGI, but as a server. I don't WANT to host |
|
102
|
my own server (and don't have the rights to on my hosters). I hate |
|
103
|
server-side maintenance (a hate born from years of administering |
|
104
|
systems). But the server has other uses. When working on the wiki, bug |
|
105
|
reports, etc., the local server is *the* way to do it. It's blazingly |
|
106
|
fast and much more productive. When you're done, just run "fossil |
|
107
|
push" and everything's synced. |
|
108
|
|
|
109
|
|
|
110
|
Point #4: the single-file repository |
|
111
|
|
|
112
|
Having all controlled content inside a single container file has been |
|
113
|
a godsend when it comes to backups and copying/moving a repository. |
|
114
|
There are no access or file ownership issues, which are often |
|
115
|
problematic with other server-side systems (at least on the initial |
|
116
|
install). For about 5 years I administered a CVS repo for a company |
|
117
|
for, and every time someone added a directory to the (huge and |
|
118
|
dynamic) source tree I had to log in and "chmod 4775" the directory |
|
119
|
before others could commit to it. Fossil's model inherently eliminates |
|
120
|
that type of problem, and I'm a *huge* fan of solutions which |
|
121
|
inherently (that is, due to their very nature) avoid certain |
|
122
|
foreseeable problems. The single-file repository model's flexibility |
|
123
|
would seem to become more problematic for huge repos (a few hundred |
|
124
|
MB+) with many users with differing levels of access (e.g. OpenOffice, |
|
125
|
Firefox, or the Linux Kernel), but 99.9% of projects never reach |
|
126
|
anywhere near that size or complexity. |
|
127
|
|
|
128
|
|
|
129
|
In summary: |
|
130
|
|
|
131
|
I remember my first reaction to fossil being, "this will be an |
|
132
|
excellent solution for small projects (like the dozens we've all got |
|
133
|
sitting on our hard drives but which don't justify the hassle of |
|
134
|
version control)." A year of daily use in over 15 source trees has |
|
135
|
confirmed that, and I continue to heartily recommend fossil to other |
|
136
|
developers I know who also have their own collection of "unhosted" pet |
|
137
|
projects. |
|
138
|
</div> |
|
139
|
|