Please document interaction between bzr and u1

I think this is covered in the backup section of the admin guide. If there are gaps in it, please ask a more specific question.

While http://doc.bazaar.canonical.com/latest/en/admin-guide/backup.html certainly describes the means by which one would backup to some arbitrary sync replicator, there are two ways in which it doesn't quite meet the goal of documenting the interaction:

1) It encourages the use of bzr pull, while for some classes of replicator, only bzr push is sensible. For example, if a user has three machines sharing some replicated store, and runs bzr pull to backup several local copies of a target branch, that branch is likely to reach an odd state in a hurry, given different potential activities on each local copy. Note also that for some classes of replicator, the user may not have the ability to execute bzr in the source, but only in some replica, running into potential timing issues if the user attempts to enable some automated backup of several replicas simultaneously.

2) Nowhere in the backup section (or anywhere else in the system admin guide I could find) is there discussion of the risks of using a replicator as a working bzr branch, where the user can easily corrupt the branch by running various bzr operations on separate replicas locally and expecting the replicator to handle the variation.

So the gist of this bug is, on the bzr side, that we should say:
"don't copy from or write into the directory while bzr is running?"

It sounds almost commonsense but it might be worth describing. Surely
this is true for most applications?

Is there any hook by which we can teach u1 to be smarter about this?
(For instance by making it look at bzr lock files?)

--
Martin <http://launchpad.net/~mbp/>

"16:08 < lifeless> poolie: the doc bug - I think we should explicitly
describe what we expect the fs to do - doing backups or any other 'read
or write data behind bzr's back' requires thought and coordination
16:08 < poolie> i am, soon
16:09 < poolie> so, essentially, the data structures are guaranteed
quiescent when bzr's not running, and otherwise not
16:09 < poolie> meaning safe to copy around
"

Emmet Hikory wrote:
> Public bug reported:
>
> Please document how u1 and bzr interact, most likely generalised.

My summary is: avoid storing bzr branches on u1.

I tried it, and it kept creating conflicts. On machine A, I'd resolve
them in favour of machine B, and this would produce new conflicts on
machine B. I'd resolve them on machine B and get conflicts on machine
A. Ad infinitum.

Aaron

Does this also apply when there is only one machine used? I.e. when bzr is used to only version files localy and u1 is used solely for backing up? My common sense understanding is that since u1 is only copying the repository to the cloud and not the other way around (i.e. all changes to files and directories are done locally), there should be no problem then, right?

Hm, just read the docs (http://doc.bazaar.canonical.com/latest/en/admin-guide/backup.html) and it seems I was not right, sorry for the disruption.

See bug 607850 for the kind of trouble you can get into by using bzr with u1 today.

@Tomas surprisingly enough (and somewhat disturbingly) u1 will apparently modify the files even when it should be doing a one way sync.

Invalid for U1 since it was shut down in 2014.

http://blog.canonical.com/2014/04/02/shutting-down-ubuntu-one-file-services/