[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is it a good idea to use CVS for this??
From: |
Rob Helmer |
Subject: |
Re: Is it a good idea to use CVS for this?? |
Date: |
Mon, 15 Oct 2001 11:07:00 -0700 |
User-agent: |
Mutt/1.2.5i |
One thing to keep in mind is that binary files are non-mergable
( at least, you don't want the output of an automatic merge by CVS,
since it won't work anymore ;) and that means that everytime you
check in a new revision of a binary file, it doubles in size.
This can easily grow way out of control.
There are better mediums for binary file storage in my opinion,
such as : burn every release copy to CD. Store on a file server
that gets nightly backups ( or FTP archive, or intranet, etc. ).
Also, everytime a client wants to check in a binary through CVS,
it will be copied to /tmp on the server side. You will need
adequate storage there.
I agree with another respondent who said to keep checksums of
your binaries, those kind of files are well suited to CVS.
Anything that is automatically mergable ( even if you never
intend to automerge on the client side ) is much much better in
CVS than a non-mergable, since on the server side ( RCS ) each
file that gets checked in can be stored once, and every subsequent
change gets stored as a diff, so the filesize taken is decreased
dramatically.
Summary : binaries don't need incremental changes, store them
somewhere safe, preferebly non-writable. Source files do need
incremental changes, so store them somewhere safe ( adequate
backups, etc. ) but store them somewhere writable, where all
incremental changes are closely tracked ( like CVS ;).
HTH,
Rob Helmer
On Mon, Oct 15, 2001 at 12:18:29PM -0400, address@hidden wrote:
> Hello all, I have been having an interesting discussion with a co-worker,
> and am looking for some additional thoughts. My organization is just
> adopting CVS, and source code management. ( don't even ask how we did it
> in the past, you don't wanna know ). Anyway, we have been discussing
> exactly what to store in CVS, and some details as to the who, what, when
> were and how, of using CVS.
>
> Well, one coworker has suggested storing the output of the build process (
> that is, the final executables, dlls, etc. ) in CVS. He makes some good
> arguments that this stuff should be archived, which I agree with. But, I
> have some reservations about putting it in CVS. I can't however, put my
> finger on exactly why I think CVS isn't the best place for this stuff.
>
> So, if anyone could share their thoughts with me, pro or con, I'd highly
> appreciate it. Do any of you store executables in CVS? What good reasons
> exist, if any, for doing this? Conversely, what good reasons, if any, exist
> for NOT doing it?
>
> Thanks!
>
>
> Phillip Rhodes
> Application Designer
> Voice Data Solutions
> 919-571-4300 x225
> address@hidden
>
> Those who are willing to sacrifice essential liberties for a little order,
> will lose both and deserve neither. - Benjamin Franklin
>
> This country, with its institutions, belongs to the people who inhabit it.
> Whenever they shall grow weary of the existing government, they can
> exercise their constitutional right of amending it, or exercise their
> revolutionary right to overthrow it. - Abraham Lincoln
>
> No citizen shall be denied the right to bear arms, if as a last resort, to
> protect themselves from tyranny in Government. - Thomas Jefferson
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>