RE: Unix philosophy under the gun?

[Ralph Mack]

> From: Matthew Riechers <address@hidden>
> Organization: GDDS
> I'll try not to get too 'religious'...

Thank you. I know this is a contentious area and I appreciate 
your restraint.

> UNIX tends to blur users and developers together, which is a 
> Good Thing for developers :)

I generally agree. Windows and Unix blur users and developers 
but in different ways - UNIX treats all users as developers and 
Windows treats most developers as users (leaving the others to
fend for themselves). In fact, both developers and users would 
generally like to be able to reach for whichever treatment they 
wish, depending upon the task they're doing and how they feel 
about it. Most developers see revision control, like backups, 
as a necessary distraction. They want to be able to do it well 
without thinking about it.

> With it, you can approach problems very efficiently, but only 
> if the tools are interoperable, and that means they have to 
> 'do one thing, and do it well'.

> CVS has a UNIX heritage -- you can take the CVS out of UNIX, 
> but you can't take the UNIX out of CVS.

Again, I generally agree. Don't get me wrong - I like the 
flexibility of UNIX. I like CVS's UNIX heritage. Every 
command-line tool on any platform that supports pipes should 
partake of that heritage.

> That glue is just pipes 90% of the time, and it allows for 
> powerful one-liners that take almost no time to write. 
>
> If your approach CVS with only a non-UNIX mindset, you are 
> effectively going against the grain, and that makes it very 
> hard to learn and use. Whether this is a strength or 
> weakness depends on the user and their environment. 

I thoroughly agree. If pipes were all that was involved with
CVS, I'd be entirely happy with it.

I'm not saying that I don't want CVS to have a rich command-line 
interface, only that I would like its default behavior to make 
more of the tool available to the user without extensive study 
and without mummifying the tool in scripts that then need to be 
maintained.

I don't think that most of what we want to do in version control
is *conceptually* difficult. Even merges are conceptually simple. 
You pick a group of files and merge the ones from this branch
into a sandbox and subsequently (on commit) into the branch that
the sandbox was drawn from. Doing them right, with the minimum 
number of merge conflicts to resolve, requires keeping a merge 
history. Right now we have to mummify CVS in scripts to create 
lots of tags to do this, especially if we want to freely merge
back and forth between branches. I think CVS should always be 
keeping the merge history behind the scenes. Then any user could 
use a single CVS command (or two) to perform the entire work of
a merge.

Likewise, we end up resorting to Perl scripts for the most basic
reporting, the equivalent of an "ls" command. Because the CVS
repository is versioned, an "ls" would have to support switches 
for selecting on tag or whatever, but the concept is the same. 
If I put something somewhere, I should be able to very trivially 
verify that it got there and see what else is in there. Then I 
can pipe the output into something else at the command line.

Now THAT is very UNIX. 

Ralph