>
> 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
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
