[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS and Binaries
Re: CVS and Binaries
Tue, 06 Nov 2001 09:56:01 -0600
[On Friday, 26 Oct 2001 17:15:21 -0400 (EDT), Greg A. Woods wrote: ]
>[ On Friday, October 26, 2001 at 10:48:20 (-0500), Jason Mowat wrote: ]
>> I want to do revision control on files such as Visio diagrams and
>> Access applications. These files are "binary" format. I am currently
>> a user of CVS for my text based source, and I am quite happy with it.
>> I have looked at Visual Source Safe, and it seems like a good tool for
>> storing files of this kind. However, I don't like the fact that I
>> have to have two sepaprate repositories: one for text base source and
>> one for binaries. Our CVS repository is also running under Linux,
>> where VSS will not run. I'd like to keep my repositories on the same
>> physical box.
>Well, like it or lump it, but you've got two very different classes of
>files that require two very different, indeed antithetical, processes
>for handling their change management. It does not make sense to try to
>lump two such different things into one tool.
>Use the right tool(s) for the job(s).
I agree that CVS is not suited to handle binary files like it does text files,
if you only need to version and branch files, and not do diffs and merges, then
CVS will probably work for you. I'm currently using it to manage the source
as well as binary content like images, PDFs, Word docs, etc. for a B2B website.
Having everything stored in one place makes releases a snap. Keep in mind
though, that every time you check in a binary file, CVS must store the entire
also keep in mind that Windows apps. (like Word) create a completely new version
of a file when you save it, even if you made no changes. If you decide to go
route, you'll probably want to update the cvswrappers file so that you don't
specify the -kb option every time you commit a binary.
>> Should I use CVS to store Visio diagrams and Access apps, or should I
>> try a different product?
>I wouldn't -- they're non-mergable files.
You can do it, but you'll lose much of the functionality of CVS and end up with
repository. Sometimes it's easier from an administrative point of view to just
in one place rather than having to go here for the code and there for the binary
content. I'm the sole UNIX guy in an almost completely Windows company/MIS
and get stuck not only doing development, but also UNIX admin and support of
and production systems, CVS repository admin and support and release management.
The company currently doesn't have a content management system for digital
and wasn't doing any kind of version control on their code until one of the
totally fsck'ed the project with old code and I was tasked with preventing it
happening in the future. I have enough hassles helping people out with CVS, let
the hassles that would be created by deploying a separate system for binary
and then having to support that system too.