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

[Peter Wolfe]

Hi All,

I am one of the list lurkers that rarely says anything but does follow
the threads of discussion.  I believe that Peter Fox (and Paul Sander
before him) has hit the core of the issue. We at our shop use CVS to
manage source code (and my definition is that of Paul Sander ...
anything that can't be derived automatically from something else). I
would suggest that the time has come to resolve this issue.  It seems to
me that Paul Sander's suggestions of adding in data types and merging
tools allows different uses of CVS by different users.  I believe that
the more flexible you make the tool the more likely it will continue to
be used AND be adopted by new users.  I would hold out Perl as an
example of a tool (in this case a language) with the philosophy of
"There's more than one way to do it".  Enforcing one way to do it is
best left up to local site (project) policy.

What say you Developers/Maintainers of CVS?  Give us a picture of the
future so that we (users) can make wise choices about what tools to
recommend to our organizations.  IMHO it would be sad to see CVS whither
away because it did not address user needs.

Peter Fox wrote:
> 
> >
> > How would I know?  I'm not a graphics artist!  I can imagine
> > the process
> > though and it doesn't seem that complex or difficult -- it's simply a
> > matter of understanding the intent of the two changes and knowing
> > whether they're in conflict or not and if they are then using
> > the intent
> > to figure out whether one must be given up, or whether both must be
> > preserved.  Fundamentally there's no difference here in how
> > you resolve
> > conflicting changes in source code, except that for most binary image
> > formats any and all changes always appear to be in conflict
> > at the data
> > representational level.
> >
> > Get your graphics people to handle that problem!  I.e. get
> > your graphics
> > files out of your CVS repository!  Together with your graphics people
> > you should define identification schemes and procedures that'll allow
> > you to create a master build process that'll pull the right graphics
> > images into the final product(s)!
> >
> > --
> >                                                       Greg A. Woods
> >
> 
> Sorry my "graphic people" are the same people who are writing Delphi code.
> They are also designing icons and images to represent the components they
> are developing. These images for internal development purposes only. i.e.
> they appear on the Delphi tool bar. We don't have a bunch of graphic artists
> to design them.
> 
> I believe that there is a fundamental difference that this thread has
> exposed.
> 
> IMHO the people who say "get your binaries out of my merging system" are
> looking very much as CVS as a tool to control parallel development of source
> code. CVS becomes a technique for applying patches to a development thread.
> 
> IMHO the people who are saying "I need to put binaries in CVS" are looking
> at using CVS for managing a project. i.e. they want to be able to have a
> single repository that they have confidence stores all the items needed to
> produce a release. CVS becomes not just a developers tool but also an
> essential part of the release mechanism. It allows the developers, build
> people, system testers and customers to agree what they are looking at.
> 
> It is also a tool to enable developers to retrieve all the components that
> they need to be able to develop. Writing the development procedures and the
> like is just so much easier with a single repository.
> 
> I think that this discussion is about two different world views. CVS as
> project management tool and CVS as patch tool. Taking the world view that
> binaries shouldn't be in CVS indicates that you don't think that CVS should
> be your main release repository. CVS becomes purely a tool for managing
> patches.
> 
> Personally, I think restricting CVS to the capability of only managing
> patches is weak. I believe that CVS could be capable of much more. The
> problem is getting people to spend development time on providing the
> necessary features. i.e. no point in complaining to the developers that CVS
> doesn't have feature 'x'.  If you want feature 'x' write it and contribute
> it. Then complain if the maintainers won't add it. Of course you'll have to
> write reasonable code.
> 
> Pete
> 
> --
> 
> 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.
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs

-- 
Peter Wolfe                      Tel: (604) 303-2300
Telos Engineering Limited,       http://www.telostech.com
120 - 13120 Vanier Place,        FAX: (604) 276-0501
Richmond, BC, V6V 2J2.           mailto:address@hidden