At 2007-03-01T20:40:39+1300, Christopher Sawtell wrote:
> 1) Can one commit binary files, such as pictures, to a monotone network?
Sure, that will work just fine. Changes between versions of a file are
stored as a description of only the differences (this is computed using the
xdelta algorithm, which is effectively byte based and will work well on any
type of file).
During the monotone summit last month, we were sharing our collection of
photos (around 1GB total) using monotone.
There are, however, a few caveats:
- The existing content merger (a line-based 3-way merger) won't work on
them. Theoretically you can tell monotone to use another merger for
certain file types, but nobody has really tried yet, so a little bit of
coding would probably be required to get this working.
Actually, that's not quite true--one of the monotone developers wrote a
special content merger that understood the formatting of ChangeLog files
and made merging them much easier as a proof of concept.
- Because monotone is primarily designed for managing source code or other
trees of files with similar characteristics, it assumes that an entire
file can be reconstructed in memory. This means that huge files won't
work well because of the memory requirements of dealing with them.
There are versioning systems around designed specifically to deal with
versioning large files (usually media). As far as I know, they're all
commercial offerings, and usually targetted at video game developers and
other areas of digital art.
> 2) Do new branches create copies of completely unchanged files, thus
> wasting disk space?
No, new branches are free in every respect. Creating a branch is just like
commiting a new revision (and takes advantage of all the same delta
compression, etc.), but happens to have a new branch named stored in the
branch certificate.
It might be easier to understand this once you realise that the concept of
branches in monotone are just a way to filter a view of the complete history
in your repository.
Imagine if you start with a single revision, A, in your repository:
A
Now, you commit a child of that, B:
A
/
B
You decide to create a new branch, and revision C is the first new revision
in that branch:
A
\
C
And then do some more work as D and E:
A
\
C
|
D
|
E
On the first branch, you commit some more work--F and G:
A
/
B
|
F
|
G
The graphs above show the view of the history with everything filtered out
except the branch you're working on. Behind the scenes, the graph really
looks like this:
A
/ \
B C
| |
F D
| |
G E
That reminds me of something I forgot to put in the 'Cool stuff' section of
my last post. Because the history is represented as a DAG, and because
monotone allows you to create a new child revision of any revision, you can
branch from or make changes against old revisions at any time in the
future. One really neat use of this is described in the DaggyFixes page in
the monotone wiki. It's too much go cover here, so I'll just link to the
wiki page: http://venge.net/mtn-wiki/DaggyFixes
Also, if anybody is playing with monotone, I recommend looking at the
monotone-viz tool. It's a visualization tool written in O'Caml that
produces very pretty graphs of the history stored in a monotone repository.
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
