bzr for documents
bignose+hates-spam at benfinney.id.au
Fri Nov 28 21:10:19 GMT 2008
"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
> 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)
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
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 |
More information about the bazaar