Best/right workflow for 'solo' use, with a remote site?

[Joke de Buhr]

In your current situation it would probably the best to create an empty bzr 
repository and import all the remote files you need. Maintaining repositories 
on two boxes is very easy if you use bazaar checkouts. That's much like svn.

You might want to place your stable websites within the repository trunk and 
develop now features within feature branches. Later on merge the feature 
branches with trunk. 
http://doc.bazaar.canonical.com/bzr.2.0/en/user-
guide/organizing_your_workspace.html#feature-branches

Combine feature branches with a centralized workflow using checkouts.
http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/centralized_workflow.html


You may want to follow my setup.
On my solo projects I'm using bazaar this way:

- The remote box acts as a central bazaar server. It's the main storage 
location for all my repositories.
- Development is done on local machines (laptop, desktop, office) using 
checkouts or bound branches.
- The development itself uses the normal bazaar workflow with feature branches. 
Small bugfixes are commit to the trunk. The main development happens in a one 
or two feature branches.
- Local feature branches are always pushed to the remote machine upon creation 
and bound to the remote location instantly.


This setup has some advantages and disadvantages:

Positive:
 - Remote is a up to date backup in case a local machine fails (laptop 
crashed/lost). Thanks to checkouts/bound branches you don't loose the work of 
an entire week.
- Local machines are a up to date backup in case remote machine fails.
- Synchronizing your data is easy (checkouts). You don't have to worry about 
starting local machines while at the office or the IP of you laptop.
- It's easy to switch to a switch to a small collaboration setup. Other users 
can branch the remote repository (read only access). You can grant write 
access to work together using checkouts or merge their changes by mailing 
merge-directives.
- Using feature branches your history stays grouped while working on different 
features. In case the feature doesn't turn out to be that good just delete the 
feature branch there is no need to revert changes from the trunk.

Negative:
 - Remote machine should be running all day.


On Monday 04 January 2010 07:10:39 Ben DJ wrote:
> I just got started with bzr.  I've got local repos setup,
> check-ins/outs are working as expected.
> 
> Starting to explore distributed use (new to me; used to central-SVN
>  server).
> 
> I'm not clear as to what the "best way" to manage my setup is -- and
> whether I should treat it differently to take any/some advantage of
> distributed features.
> 
> My setup's pretty simple (atm):
> 
>    One local box, with my entire dev environment on it.
>    One remote box, user for a production website, with pre-existing
>  website.
> 
> Until now, I've been developing ON the remote box's files.
> 
> Now, I want to create a working env on my local box, starting with a
> copy/clone of the remote webserver's data files, do all dev and
> version mgmt locally, and then push chosen versions into production on
> the remote box.
> 
> I've seen steps for creating a bzr repo from scratch, and from a
> preexisting local dir, but, again, am not clear how to best handle the
> remote's files.
> 
> Should I create/maintain bzr repos on BOTH boxes, and somehow 'sync'
> them using the distributed capabilities?
> Or, instead, mount the remote locally via sshfs and treat its files as
> local to my local dev env?
> 
> Any suggestions/pointers as to the right way to manage this would be
> appreciated!
> 
> BenDJ
>