bzr for documents

[Ben Finney]

"Rustom Mody" <rustompmody at gmail.com> writes:

> I dont know if this is right use for bzr (or if this is a very basic
> question :-)
> I want to use bzr for text documents -- usually emacs-org files.

That's an ideal usage of a version control system, and Bazaar will do
nicely.

> The usage scenario is
> 
> 1. Files reside in a number of different directories

One assumption of Bazaar is that files stored in the same directory
are stored there because they are conceptually related for some
purpose, and a tree of directories is likewise conceptually a
hierarchy of related files and directories.

> 2. Many (one-off) documents may not be versioned

Are you saying it would be *bad* to version-control such files? If
files are hand-edited and kept together, there's little reason to
avoid version-controlling them unless you have some special need that
isn't explicit here.

> 3. Their histories are usually unrelated

Presumably, though, they are related in that they are “about” the
same thing and should be tracked together.

> 4. Documents that are versioned may have complex (branching)
> histories

Yes, Bazaar will certainly suit this purpose.

> -- Am I required to keep the .bzr directories in each directory
> where versioned files reside? Or can I have one repo for all
> versioned files?

Bazaar treats a hierarchy of directories and subdirectories as a
conceptual whole, called a “working tree”. There is one ‘.bzr’
directory, at the root of that tree.

> -- How do I disentangle the histories of different (unrelated) that
> simply happen to be in the same directory.

You can operate on individual files within a working tree where that
makes sense; most operations will also default to operating on the
entire working tree if no files are specified.

> -- I grew up on rcs (about 15 years ago). Is there not an
> 'rcs-workflow' ie a file oriented rather than directory oriented
> one?

No, Bazaar works on whole working trees as the unit to be tracked.
This allows, e.g., file renames within a working tree to be tracked as
a change, instead of disjoint history.

> -- Should not the user guide have a 'document management workflow'
> along with the others? Or my question(s) are a little stupid :-)

What do you find lacking in the existing “project management
workflow”? I apply those concepts directly to my ‘$HOME/Documents/’
subdirectories. That's not to say there aren't improvements, but I
don't know what you'd want.

-- 
 \         “A fine is a tax for doing wrong. A tax is a fine for doing |
  `\                                                 well.” —anonymous |
_o__)                                                                  |
Ben Finney