info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BRANCH LABEL FOR DIRECTORIES


From: Ralph Mack
Subject: Re: BRANCH LABEL FOR DIRECTORIES
Date: Tue, 19 Jun 2001 08:50:34 -0400

>> cp olddir/oldfile.c newdir/newfile.c
>> cp olddir/oldfile2.c newdir/newfile2.c
>> cvs rm -f olddir/*
>> cvs add newdir/newfile.c newdir/newfile2.c
>> cvs commit -m 'reorganized source to be better'
>> cvs update -P

> However I can't let that sit.  What a downright stupid and misleading
> example.  

This doesn't seem like a manufactured scenario to me - more like something
that comes up every so often, although I'll admit it has fewer files than 
the normal case. It looks like what I would do if you had to move the 
contents of a directory from one place in the directory tree to another? 
How would you do it, Greg? 

It isn't enough to say that you simply wouldn't let this happen to you.
Migrations, even mass migrations, are a fact of life; demands of logistics
often place their prevention beyond our control; since they cannot be 
prevented, they need to be supported without damaging continuity.

> CVS isn't a market driven product -- it's a freeware niche product.

I don't see CVS as a niche product at all. CVS is as mainstream as Linux
or Java. Most of what most people need is easy to learn and use, with 
the exception of branches and merges. Set up is kind of fragmentary, as
for many Linux services, but it seems to have all the right hooks in all 
the right places for integration into corporate build mechanisms. Its
support for Windows clients is adequate. As companies become more 
accustomed to shareware, I could see it become the preferred version 
control system for corporate Unix/Linux. If the Windows version could 
register out of the box as a Win2000 service, I could see it becoming 
popular for Windows shops, too.

Its biggest drawback as a mainstream product is that branching and 
merging require you to know a lot more than with other products and
require certain voluntary behaviors that aren't immediately obvious,
like tagging on both branches when doing merges. A few enhancements, 
like tracking moves, renames, and merges will permit reasonable default 
behavior in most situations for those developers who do not have a 
passionate interest in revision control.

Ralph A. Mack




reply via email to

[Prev in Thread] Current Thread [Next in Thread]