> I have been using Subversion for this very application for several
> years; it works well.
Most revision control systems will do the job. And most of the post-CVS
revision control systems (other than Subversion) also allow you to commit
locally before sending the commit to the remote server. They also all
(except for Subversion again, AFAIK) keep track of merges, in case you use
branches.
All in all, Subversion is probably the least flexible of the new tools.
Of course, it doesn't mean it's bad, just that it's worth taking a look
at alternatives.
> Subversion doesn't care; it handles any file type, including binaries.
The problem is in what is meant by "handle". Being able to store and
retrieve arbitrary revisions is easy. Doing it half-efficiently with binary
data is terribly hard.
But the main problem is how to do merges since the merge algorithm
necessarily needs to understand something about the structure of the file.
In general, it requires intelligence. In the case of OOs files, you'll need
to ask OOo to (help you) do the merge.
> or for revisions made to dozens of documents. But Subversion uses a
> "diff" technique, so the size of the repository grows very little from
> one revision to the next, unless you are adding much new material.
A diff between two compressed versions of very similar files may still be
just as big as the compressed file.
> And with Subversion, you always can go back to any previous version of
> any document. You can return even to a previous version of a document
> which you have removed from the repository; this is a consequence of
All revision control systems can do that, even the ancient ones.
Stefan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
