info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: How well does CVS handle other types of data?


From: Peter Fox
Subject: RE: How well does CVS handle other types of data?
Date: Wed, 11 Jul 2001 13:28:55 -0400

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Wednesday, July 11, 2001 11:44 AM
> To: Daniel Beckham
> Cc: CVS-II Discussion Mailing List
> Subject: Re: How well does CVS handle other types of data?
> 
> 
> [ On Wednesday, July 11, 2001 at 08:52:37 (-0500), Daniel 
> Beckham wrote: ]
> > Subject: Re: How well does CVS handle other types of data?
> >
> > Greg, as someone else pointed out.  It's a rare project 
> that does not have a
> > few binary files peppered in the source for various 
> reasons.  Although, in
> > your mind it would make the most sense to maintain those in 
> a seperate
> > facility, in my opinion, it's stupid and inefficient.
> 
> The more rare the binary files, the more sense it makes to keep them
> separately.
> 
> The more common the binary files, the more sens it makes to use
> something other than CVS (if not for them then for everything!)
> 
I disagree. The more rare the binary files the more sense it makes to check
them into CVS to ensure that they don't get overlooked. Making a special
case of any file is dangerous as you have to remember to do things with it.

By checking the file in you have to handle the special case when you first
add it. i.e. use the -kb option. Better still the administrator makes it a
special options once by playing with the cvswrappers file. After this you
don't have to worry about it being a special case.

By storing the files in a separate location you have to manage another
source control system. Every time a developer checks out a project or a
build management team wants to build a project they have to remember the
special case.

I would agree that if you are exclusively storing binary files then CVS may
not be the best option. CVS will not store such files efficiently and can
consume large amounts of disk space. You are probably better off with a
document management system of some kind. But... if you have the disk space,
don't need branching then it could well fit the bill. 


> >  Just because you
> > don't need to merge those binary files doesn't mean you 
> don't want to keep
> > track of their history, etc.   As others have pointed out, 
> cvs handles them
> > just fine if you use the -kb option.
> 
> It's irrelivent whether or not you "need" to merge binary files.  You
> may *have* to!!!!  If you use branches, and if changes to binary files
> are made on branches then you _MUST_ "merge" them!!!  CVS 
> simply cannot
> do that and the only way to resolve the conflict is to choose one
> revision.  If you're lucky there'll only be one or two such conflicts
> during a branch merge and manual cleanup is easy.  However if 
> you've got
> dozens of GIFs, for example, and you end up with a conflict on each,
> then you're in for a much more difficult cleanup.
> 
You will never HAVE to merge binary files. If you have binary files you have
to adapt your development procedures to deal with this

If you have many people working on editing graphic files you'll probably
find that you can't use branching and must us a lock file, edit, check in
mode of operation. I know this is flame bait on this list, but not every
project deals exclusively with 'C' source code. 

In a PC GUI based software development project you almost certainly want
some GIF files around. If some one goes out on a branch and edits a number
of the existing GIF files and then wishes to merge back into the HEAD then
they almost certainly want to replace the HEAD GIFs with there own.
Branching is not an issue. 

CVS provides many facilities that are useful in managing project
development, i.e. labelling, single repository, that it would be wasteful to
throw away just because you don't wish to use branching.


> > And in rebuttle to your comment.. there is no right tool 
> for the job.
> 
> What are you talking about?  Of course there's a "right" tool, even if
> its some lame script you write that used gtar over SSH and carefully
> named files and directories!
> 

But why re-invent the wheel. If CVS gives you 95% of what you want, when
spend 10 weeks on obtaining the last 5%. It's not worth it. 

Peter Fox



> -- 
>                                                       Greg A. Woods
> 
> +1 416 218-0098      VE3TCP      <address@hidden>     
> <address@hidden>
> Planix, Inc. <address@hidden>;   Secrets of the Weird 
> <address@hidden>
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 


--

NOTICE:  The information contained in this electronic mail transmission is
intended by Convergys Corporation for the use of the named individual or
entity to which it is directed and may contain information that is
privileged or otherwise confidential.  If you have received this electronic
mail transmission in error, please delete it from your system without
copying or forwarding it, and notify the sender of the error by reply email
or by telephone (collect), so that the sender's address records can be
corrected.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]