[no subject]

> <4794968D.8080501@fs.ei.tum.de> <4794a63c$0$854$415eb37d@crater_reader.dragonflybsd.org>
From: "Simon 'corecode' Schubert" <corecode@fs.ei.tum.de>
Subject: Re: cvsup
Date: Mon, 21 Jan 2008 15:52:32 +0100
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:users@crater.dragonflybsd.org>
List-Subscribe: <mailto:users-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:users-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:users-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-users@crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
In-Reply-To: <4794a63c$0$854$415eb37d@crater_reader.dragonflybsd.org>
Sender: users-errors@crater.dragonflybsd.org
Errors-To: users-errors@crater.dragonflybsd.org
Lines: 81
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1200927953 crater_reader.dragonflybsd.org 854 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.users:10345

Bill Hacker wrote:
>>  I can't run a patch and work on a different issue
>> myself - I'll mix both.  Or I'll have to check out into another tree and
>> lose the patch.
> Indeed. And have to go find it and manually re-apply, and/or alter and
> re-apply 'coz it no longer fits quite tha same on code that has moved on
> in other details.

And once you've applied it, it is mixed with your existing changes.
That's the main problem.

> But unless and until the patch is vetted and accepted into the
> mainstream that is exactly what a 'production' user wants.

A production user doesn't want patches or something else.  He wants
working binaries.

> As said - developers and production users have different priorities and
> CVS is a fairly effective compromise - ELSE it would have been scrapped
> long ago by a lot more projects than have done so to date.

No, that's not true.  It's just that developers are lazy and don't want
to learn new, potentially better tools.  They are also conservative and
don't want to change one tool for the other without real benefit.
Several projects did the mistake to convert from cvs to svn, which
didn't really improve productivity (I guess).

>>> Rather than 'nag' - set up what you want and see who joins or lends a
>>> hand.
>> It is really cumbersome to keep any repo synchronized, especially if you
>> want to have a nice repo which reflects vendor branches correctly.
> Understood. But *any* repo and any toolset needs effort.

No doubt.  The differences, however, are orders of magnitude.

>> Basically all manual CVS interference has to be dealt with either in the
>> tool or manually.
> Alternatives may provide more comfortable knobs and buttons - but AFAIK,
> none of them yet read minds, let alone cover the sharp edges.

Oh yes, they do cover sharp edges.  They might have other, different
ones, but not as many and not as sharp (I'm obviously biased).

> But if your peer contributors - who must have nearly identical concerns
> - don't yet see CVS as a target for 'real soon now' replacement, there
> must not (yet) be an overwhelming case for change.

Oh yes, everybody who EVER tried adding third party software to the
repo, or rather kept maintaining it, has been swearing on CVS.  Even
Matt decided that CVS was evil and started the whole patch thing.  The
patches helped on one side but are hurting on the other side - much
more.  The real salvation is a version control system which will help
the developers in their tasks - not stand them in the way.

> Change can't take place until it is possible for those involved to eval
> both tools side-by-side - on DragonFly, not 'other project x' - until
> they are convinced the advantage is worthwhile AND will not make it
> harder in general to use.

No doubt.  Bear in mind that every new tool needs some effort to learn.
 This means that everybody involved has to accept the fact that they
need to put some effort in in order to be able to fairly evaluate the
tool.  So a learning curve has to be expected.

> I'm not defending CVS in particular. I'm just saying if *most* folks
> don't see <whatever> as broken a fix won't get a lot of followers.

People still program in C.  People keep writing shell scripts.  *Most*
people don't realize the shortcomings of the tools they are using
because they a) they don't reflect on their workflows and they are b)
too lazy to check out alternatives to realize there is help.

> .or we would have left 'C' for something else about fifteen years ago,
> let alone the x86 archeologitecture.

You exactly nailed the point.  People don't want to move.  They don't
want to learn.  Even if the alternative would be orders of magnitude better.

cheers
  simon