>--- Forwarded mail from [EMAIL PROTECTED] (Greg Woods)
>[ On Tuesday, February 15, 2000 at 18:10:16 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS File Locking
>>
>> Keep in mind that the choice is to decide which change disappears
>> into the ether, and the answer may be a very impractical "neither".
>> It would be better to avoid the situation where such a choice is
>> required.
>Yes, of course. The solution in that case is trivial (though perhaps
>undesirable -- but, TANSTAAFL): simply re-do one of the changes using
>the other as a baseline to start from.
>> I would like to hear about another method that avoids the choice I've
>> described above that doesn't rely on serialized development. I, personally,
>> don't know of one, but then you might know something I don't.
>The other method, described just above, has been in use long before
>sophisticated version control tools existed.
But as you say, that method is undesirable. It represents the loss and
repetition of work in an error-prone way. It's better to avoid such a
situation.
>> The key here is "in their experience". Their source files fit a very
>> narrow standard, one that doesn't fit many real-world projects that were
>> initiated in the decade or so since that paper was written.
>Ah, but in the real world (at least that portion that can make the best
>use of a tool like CVS) source files are almost always text files and
>most computer scientists agree that version control should be done only
>on the source files in order to maintain a hygienic development
>environment.
I'll take exception to your claim that "in the real world source files are
almost always text files". It may be true that 90+% of them really are text,
but there are typically some that are not. Resource files for GUI libraries
and image files readily come to mind. There are also various forms of
documentation which are thought of as text but really aren't (e.g. Word
and Frame Maker source files). Some shops also include design documents
as part of their source code, and they are almost never text, if they're
products of, say, a requements verification tool.
>A better question is to ask why some language developers fail to think
>of the issues of change management and heterogeneous development
>environments when they devise their code storage file formats. The
>person who devised VisualBASIC files should have very nasty things done
>to him/her for all eternity. There are more VB programmers than any
>other kind and they've all be forced into the purgatory of having bad
>version control because of this insanity. Perhaps they should be there
>for other reasons, but this isn't one of them! The next person who
>develops an integrated programming environment and leaves out the change
>management side of things should have a million sharp-pointed binary
>changes jabbed into them!
I think we agree that many product developers are not cognizent of release
mangement or even source management issues. They just use the tools and
let someone else handle the details. These are the people who design
unmergeable file formats. And a tool's audience generally has very little
influence on the internal representations of the data, so pressuring the
vendor will have limited success.
>> I'm sure that
>> if Prisma required more than a few files that didn't fit that standard, CVS
>> would somehow support them.
>I seriously doubt it. CVS is what it is only because it limits its
>solution domain to a practical scope.
Given that the issue of expanding the usability of CVS into new areas
was left open, I don't share your doubt.
>> Maybe they did, and relegated their ownership
>> to a very small group of people who practiced serial development informally;
>> such efforts would likely have been omitted from the paper for any of a
>> number of reasons.
>Why don't you ask?
Because the email addresses I have for Brian Berliner and Jeff Polk are
long since obsolete.
>Better yet why don't you find out why almost all source code control
>systems make the assumption that source files are "text" files? :-)
None of the commercial systems I've evaluated or developed (yes, I once
did development for a commercial vendor of a source code management system)
has made that assumption.
>--- End of forwarded message from [EMAIL PROTECTED]
