Re: Need advice on 1) binary files, 2) locking

[Paul Sander]

>--- Forwarded mail from address@hidden

>[Paul Sander - Mon at 07:15:45PM -0700]
>> >2. If so, is there a way to make CVS use exclusive file locks - a la RCS &
>> >SCCS?
>> 
>> There is a patch that changes CVS in such a way that with selected files
>> users must declare their intent to modify a file before they can commit
>> changes.  These have been described as advisory locks, but they are not
>> exclusive, and they are easily defeated using the CVS command line interface.

>According to the ACL discussion, CVS is not a security tool, hence it would
>be very hard to make anything else than advisory locks.

CVS, like any other application, can control how its users access its
data.  It doesn't need to be a security tool to do that.

>The idea behind CVS is that locks never should be needed.  With a bare
>minimum of cooperation and communication (...and the watchers feature in CVS
>can be a smart way of discovering that communication is needed), the most
>obvious conflicts should be avoided, and it usually should be okay to merge
>the files anyway.  Of course, merging is not trivial when it comes to binary
>files - but then again, if two editions of a file cannot be merged, you
>probably won't need advanced version control anyway, merely an archive of
>old versions and a changelog.

This argument has been made before many times.  The counterargument is
that having a single version control system is much easier on the users.
Also, version control _is_ needed even on binary files that are undergoing
active development, even if they can't be merged.

>I do see situations where putting _some_ binary files into a cvs repository
>would be convinient, but I think using CVS as a version control scheme for
>binary files only makes sense if the files easily can be wrapped into text
>files, and merged somehow.

Unfortunately, there aren't many ways to wrap bitmap images in text
files that can still be merged.  Some image formats can be converted
that way, but not the ones most popular for web design and icon images
used in GUI designs.  There's also the larger picture to consider,
such as design documents and models that get stored in opaque formats
and have no merge tools.

>> CVS can work if you apply a bunch of patches and try to keep up.  However,
>> the patches mentioned above do not have wide support in the CVS community,
>> and you can't count on them being compatible with future releases.

>If nothing else, it should be a simple task to make an external script that
>fixes some kind of advisory lock.  PS: I'm currently unemployed :-)

>I'd say using external scripts are far better than applying hacks and
>patches to the cvs source.

The CVS command line interface is pretty poorly defined because it's
hard for external scripts to determine what has really happened without
a sophisticated parser on its output and examining the contents of files
in the sandbox.  And because the output of CVS is pretty much undocumented
free-form prose, any scripts that try to parse it _are_ hacks.  And then
there's the exit code issue...

I find that changes of this nature are faster, more robust, and easier on
the users if done within CVS than in wrappers.

>--- End of forwarded message from address@hidden