Re: The essential problems of moving from CVS

["D. Richard Hipp" <drh%hwaci.com@localhost>]

On Jan 18, 2010, at 4:08 PM, Julio Merino wrote:
> 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.

I'm familiar with Monotone.  Monotone was one of the original if not  
*the* original DVCSes.  (It is the first DVCS that I was aware of.)   
Linus Torvalds studied monotone after the bitkeeper fiasco and modeled  
many of his ideas for git on what he saw in monotone.  The story is  
that he would have selected monotone for use by the linux kernel  
except that the particular version he tried had a bug that made it  
really really slow.

The similarities between Fossil and Monotone are mostly superficial.   
Fossil is not really built around SQLite; it uses SQLite as a local  
cache.  The difference there is subtle  and perhaps unimportant to  
ordinary users, but people who like to ponder the philosophical  
underpinnings of version control might find it interesting.  See http://www.fossil-scm.org/fossil/doc/tip/www/theory1.wiki 
 for some recent thoughts on this.


> 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?

Fossil has what we call "autosync" mode.  (See http://www.fossil-scm.org/fossil/doc/tip/www/concepts.wiki#workflow 
 for details).  Autosync mode means that fossil does a "pull" prior  
to any "update" or "commit" and a "push" after every "commit".   
Autosync mode makes fossil work somewhat like CVS in that it keeps the  
local repository in sync with the master repository and thereby  
prevents needless forking and merging of the tree.  Obviously,  
autosync doesn't work when you are off network, so it can be turned  
off.  That is easy to do:

    fossil setting autosync off
    fossil setting autosync on

In an ideal world, Fossil would autodetect whether or not it was off  
network and do the right thing.  But that detail has been implemented  
yet.  Patches accepted!

> - 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.

When working disconnected, you commit into your local repository.   
Later, when you get back on network, you sync with the master  
repository and your commits become a fork in the change DAG separate  
from commits made by your colleagues.  At that point you usually want  
to merge so that everyone is working off of the same baseline.

Merging in Fossil is done in the local checkout.  You first "update"  
to the version you want to merge into, then you "merge" with some  
other version, then you commit.  Most people like to test in between  
the merge and commit steps.

When working on network, the default workflow is similar to CVS.  If  
you make some changes and then go to commit, but somebody else has  
already committed ahead of you, the commit will fail with an error.   
You can then "update" to merge in their change locally and commit  
again.  Or, if you prefer the monotone way, you can "commit" with a -- 
force flag which will check-in just your changes as a new fork.  Then  
you do a merge and another commit.  If you "update" before committing  
and update creates a big mess of conflicts (which sometimes happens  
with CVS) in Fossil you can "undo" the update.  So unlike CVS,  
"update" is a safe operation in that you can always get back to where  
you were before the update by using "undo".

"Forking" and "branching" differ in intent.  See http://www.fossil-scm.org/fossil/doc/tip/www/branching.wiki 
 for further discussion of the difference between the two.

> Thanks!
>
> --
> Julio Merino

D. Richard Hipp
drh%hwaci.com@localhost