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

[Greg A. Woods]

[ On Friday, July 13, 2001 at 11:06:30 (+1000), Sven Dowideit wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Greg - what is wrong with providing extra support for non-mergable files?

There wouldn't be any problem if you could do it without breaking either
the design or backwards compatability of the repository....

I invite you to write both a concrete detailed implementation proposal,
as well as perhaps an example implementation, if you think otherwise.

> Would it not be more useful to be able to set a file to be non-mergable, and
> then add support to require a lock to be placed on that file before changes
> can be allowed to be committed.

You really can't do that without breaking the design and the
expectations it sets for users.

> The only remaining issue would be the merging of branches, and again this
> seems trivial - simply leave it up to the user to decide what to do!

That's where we're at now and that's why this stupid issue keeps rearing
its ugly head.

If instead CVS made the explicit decision to not allow binary files in
the first place then we'd be on even ground and everyone would have the
appropriate expectations.

> I come from the group of developers (which i thought was in the majority
> until i came here..) that want to be able to build an application by doing
> no more than 2 steps.
> 
>    * cvs -d pserver::address@hidden:/thingy co app
>    * make app
> 
> and i do not have file system access to some other directory as i am working
> remotely

I think you need to whack your developers with a great large reality stick!

That's just not the way CVS is itended to work, except maybe in the most
trivial cases, or maybe in cases where portability is not a concern.

Even in a carefully designed project that follows the GNU Coding rules,
you'll still have to initially build all the non-committable non-source
files (eg. the configure script, etc.).

Note that if you're creating a source distribution for a project that
follows the GNU Coding rules though you'll have to do those several
extra steps after you do "cvs export -kv" and before you bundle up the
resulting source archive.

In either case these are the places where you'd copy into your source
distribution (or build directory in the former case) all those
non-mergable files.

I've already implemented all this stuff at least once for GNU Automake
(well I only provided the hooks necessary for getting extra files, such
as non-mergable files from some other repository) into the distribution,
but all the other bits are done such that "make dist" tags and creates a
proper GNU-compliant source distribution.  Unfortunately my changes were
to a slightly out-of-date (and now very out-of-date) Automake version
and they've never made it into the main distribution.

> I don't think that any of us really want cvs to merge non-mergable files,
> just to provide for what we consider a reality - some way of more gracefully
> handling them..

There are trivial ways to deal with minor numbers of non-mergable files
in the context of using CVS for your mergable source code.  I've already
outlined them, and I've used them time and time again myself.  I don't
know that I'd call them "graceful" 

If you've got bigger problems than that then you should probaly look
elsewhere for an entirely different version control and/or configuration
management system.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>