Hi,
I'm not a boost contributor (yet) and maybe can be considered novice so take my advice knowing that.

On Sat, Jan 29, 2011 at 11:08, John Maddock <boost.regex@virgin.net> wrote:
* I happen to like the fact that SVN stores things *not on my hard drive*, it means I just don't have to worry about what happens if my laptop goes belly up, gets lost, stolen, dropped, or heaven forbid "coffeed".  On the other hand the "instant" commits and version history from a local copy would be nice...

I have the same kind of concerns. 
I've only started using Mercurial (hg) in the middle of the last year and I'm not an expert but the decentralized way of doing things changes a lot my point of view. (I used SVN before)

The decentralized nature of the repositories moves the organization responsability from the tool (like in SVN) to the user (like in any DSVC). What I mean is that as every developer have a full repository, or several clones, the communication of changes between repositories is only driven by the contributors/team organisation.

For this specific point, habing a non-local clone of your work, here is what I'm doing for all my projects now:

1. On my laptop, that I use in transit, I have one repository of my project. You could say it's my "trunk", comming from the SVN world.

2. On the same laptop, I have several clones of the 1. repo. In each, I work on experimental features that I often just delete after some tests. If the feature is good enough, I "push" the changes (the commits that have been done in this local repo) in the repo 1..  That means I have to merge before sometimes as I still work on 1. for the main features, and I kind of work like if I was a big team alone. Anyway, I already can fork for myself with decentralized repositories, allowing me to experiment more easily.

3. I have another repo on my home desktop. That's a clone from 1. with some other works that require me to have several computer screens available, so I work on those features mainly on my desktop. In fact I swith from laptop to desktop often, and often make sure both are synchronised. I don't know about how it's done in git but hg (using tortoise hg or not) can setup an http server for you that will listen for pull and push requests. So it's super-easy to just transfer changes between my computers, from 1. or 2. or 3., to any one of them. In fact, I start to build some kind of hierarchical relation between my repos (that becomes natural when you understand the potential of "cloning"/"forking"). So I have two computers as various backups.

4. I don't trust my hardware very much, and sometimes I need to have changes from my desktop in my laptop but I'm too far from it, like in another city. So, I also keep another repo in my online server (an ubuntu box that I loan mostly for websites and SVN repo, nothing special). In this repo I push changes from laptop and desktop that are not experimental. 
By the way, hg works with ssh so it's incredible to see that you just have to clone a repo to make it available online via ssh (if it's not public, or with more security if it is). You don't have to launch any server (other than the one to manage ssh). 
My online server is kind of a more secure backup that is available from anywhere.

5. I also have other repos on my servers that are for my personal work that is experimental but takes a lot of time. So I still have an online available backup.

6. I have some friends that want to work with me on my project. I've setup clones for them on my private server, one for each user. They can work however they want on their local computers and simply push their changes in my private server, on their dedicated repository on my server. When they think they made works that can be used and is complete, and is all pushed in their repo, they mail me to make me review their changes, comment and if all is fine then pull the changes in the "truth" repo that merge all the team effort. That truth repo is in fact a clone of mine that I call the "team" repo. But anyway I can call it what I like, it's just an organisation matter. Like setting up the "graph" of your team :)

7. In fact, some of my projects are open-source (not worth showing here and it's not the point) so I have additional repositories in bitbucket.org and google code hosting. That way, anyone can do like any teammate from my private projects. It's just that the repository is available publicly in read-only access. To "write", people have to ask me to review their code, then if I htink it's worth and follow my standards for the project, I pull the changes and add a line somewhere about who contributed to what. For open source project, public repos are my "trust" repos, where I pull all work that is valid and finished. Note that bitbucket and github allows you with "one click" as pointed by Dean to clone a repo. That allows you to work on your version for a time, pull public changes while you still work on your features, then ask for the maintainer of the truth repo to get your changes. Or not. 

8. I don't trust all hosting services, so I've setup scripts that pull all public and private changes in separate backup repos. 

9. I didn't even started to talk about branching. Branching is kept in the repositories history, while forking is not. I have branches for features that are required, not experimental, but are long to implement. 

So, for the security of backup problems, it diseapear because it's easier to setup any dsvc hosting than with SVN (because there is no need for a server to listen). 
Some other points in my description might help to understand why decentralised changes everything when coming from SVN.

Someone (Dean?) did that analogy some time ago : SVN/CVS are like mutexes over a container while DSVC are like lockfree containers.
That's, I think, the most accurate analogy of the differencies between the two. 

I have not used DSVC for years because I thought that it was not worth it in team environnement, "because" of the decentralized nature. In fact I tried only because it was good for one person project in my mind. I must say I was totally wrong, it's the exact opposite. 

That said, I'm juste a "junior", so again take my experience as such.

Joël Lamotte