Hi,
> I began looking into fossil because I wanted a *simple* and *easy* SCM
> that I could give to people who are not experienced with SCMs. My boss
> asked me to find a solution to let people contribute to small
> developing projects. Many of these are students, others are school
> teachers who taught themselves basic programming skills. The idea is
> to have a place for them to put their code, without creating a lot of
> complexity or difficulty for them.
Then use Visual SourceSafe, or Subversion. They are simple to
understand: a network filesystem with an added dimension for time
(revisions).
With any DVCS users must understand the distinction between a repository
and a working set, and they must understand branching and merging.
Obtaining the files changes from "get" (or checkout or update, depending
on your VCS) to "clone, open" or "pull, update". Committing a change
changes from "commit" (or checkin) to "commit, push". The extra steps
are not obvious to users who don't understand the DVCS paradigm, and can
be very confusing ("I committed it, why can't he see it?" "Oh, you
committed it but you didn't push it" "?!?").
These are not simple concepts. In development companies it can take new
recruits (graduates, possibly with experience) weeks to get comfortable
with a VCS, and indications are that DVCS takes longer.
You also need to have all your projects in one repository, or one
repository per project. Unlike a centralised VCS, partial (subtree)
checkouts are not possible. So the former option just means extra
traffic and storing for someone working on a single project; the latter
means extra working if you need to sync and work on multiple projects.
Furthermore the granularity of access control is at repository level
(you either have access to the entire contents of a repository, or to no
contents of the repository).
> I began looking at fossil because it claimed to be simple and easy
> (plus I liked the incorporated wiki and bug tracker). After evaluating
> it for a few days, I am leaning to think that fossil is *not* that
> simple and that it is *not* suitable for beginners who don't have a
> lot of patience or knowledge.
Since I'm not a beginner I can't comment on that ;p
On the other hand I don't have a lot of patience. When I started with
Fossil a few months back, it was after evaluating (read: install on my
PC, play with, install on a server, play more) bazaar and hg. Fossil
was significantly easier to use both locally and to get working on a
server (I would use the word "trivial" for server installation, quite
unlike bazaar/hg).
>> Let's say we took the second option. While I'm working in B, I
>> finish my work in A. I push my changes and delete A ... and WHOOPS!
>> I just screwed up B, didn't I?
> Why would that screw up B? If making a little branch like that screws
> up the SCM then the SCM sucks. The whole reasons why we have SCMs so
> to allow concurrent development.
When you clone REMOTE to A, a note is made in A that you cloned from
REMOTE. So when you are working in A and you push or pull or sync it
knows that the endpoint of that operation is REMOTE.
When you clone A to B, a note is made in B that you cloned from A. So
when you are working in B and you push or pull or sync it knows that the
endpoint of that operation is A.
Then you delete A. And you go into B and make some changes, and commit,
and push. And it says "Can't. A is missing". And you have to
explicitly tell it that you want to sync with REMOTE instead of A.
That sequence applies to Fossil, Git, Hg, Bazaar, and DVCS in general.
It also leads to some WTF behaviour. For example, you make a change to
A, commit, push. Then you make a change to B, commit, push. Then you
delete both A and B because you've finished and pushed the changes.
Did you notice that you lost the changes you made in B? Because you
pushed them to A, not to REMOTE? That happens a lot with new users of
git, bazaar and hg, because each working set on your PC has an attached
repository. With Fossil there is one local repository with multiple
local working sets, so you don't have this problem.
>> Fossil keeps the concept of the repository and the working set distinct.
>
> Btw, AFAIK the only SCM that joins these concepts is Darcs.
Wrong. Git, Hg and (depending on your workflow) Bazaar all keep a
repository clone local to the working set. Then they muck with
hardlinks and copy-on-write to try and conserve disk space and improve
performance. (You don't want to use these on a FAT32 filesystem)
Regards,
Twylite
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
