Re: The essential problems of moving from CVS

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Mon, Jan 18, 2010 at 6:59 PM, D. Richard Hipp <drh%hwaci.com@localhost> 
wrote:
>
> On Jan 18, 2010, at 12:13 PM, bharder wrote:
>>
>> I've cc:'d drh, guessing he might be interested in at least watching
>> fossil (potentially) being considered for such a sizeable project as
>> NetBSD, and perhaps commenting on it's suitability.
>
>
> Greetings all NetBSDers.  I am Richard Hipp, the designer and maintainer of
> Fossil (and SQLite) and I would like to offer my views:
>
> Fossil was created by me for my needs.  It wasn't really designed to handle
> a project like NetBSD.  But on the other hand, as with many software
> projects, Fossil has ended up being used successfully in ways far different
> from what it was designed for.  Even I'm using it differently from what I
> original envisioned.  So Fossil might work well for NetBSD.  Or it might
> not.  I don't know your workflows, so I can't really say for sure.  What I
> can do is try to give you some insight into the differences between Fossil
> and other VCSes.
>
> Distributed VCSes (DVCSes) have many advantages over more traditional
> central-server VCSes like CVS and subversion.  No doubt you've already been
> over that ground.  But DVCSes also have some big disadvantages.  DVCSes
> encourage lots of branching.  And they force you to do lots of merging.  And
> DVCSes do not have a central place to go look for all the action.
>
> Fossil tries to take a middle approach.  Fossil allows you to have a central
[...]

Thanks for the detailed explanation!

From what I read, fossil looks quite similar to monotone!  Basically:

- monotone uses sqlite for internal storage.

- monotone doesn't encourage branching as much as git, as in there are
some well-defined public branches where different people commit to,
and then, within each branch, there can exist unnamed mini-branches
for concurrent development.  However, there is no central server: a
central server is defined by policy, not by the implementation.

- monotone is also slower than git, in part, due to extensive internal
sanity checks.  Your arguments supporting these are the same given to
support monotone ;)

Just mentioning these points in case you didn't know about monotone.

A couple of questions that you may want to answer here so that it is
easier for the readers to find the answer to:

- You mention that fossil differentiates between connected and
disconnected operation.  How does this work?  Do you need to tell it
explicitly that you are disconnected?

- How do you manage merges after having worked disconnectedly, e.g. on
a plane?  I really like monotone's approach of commit first, merge
later, as opposed to other system's sync first, merge in working copy.

Thanks!

-- 
Julio Merino