[Top][All Lists]
[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
- Re: BRANCH LABEL FOR DIRECTORIES, (continued)
Re: BRANCH LABEL FOR DIRECTORIES, Ralph Mack, 2001/06/19
Re: BRANCH LABEL FOR DIRECTORIES,
Ralph Mack <=
Re: BRANCH LABEL FOR DIRECTORIES, Ralph Mack, 2001/06/20