cvsup

[Bill Hacker]

> <4794968D.8080501 at fs.ei.tum.de>
In-Reply-To: <4794968D.8080501 at fs.ei.tum.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 79
Message-ID: <4794a63c$0$854$415eb37d at crater_reader.dragonflybsd.org>
NNTP-Posting-Host: 75.75.30.250
X-Trace: 1200924221 crater_reader.dragonflybsd.org 854 75.75.30.250
Xref: crater_reader.dragonflybsd.org dragonfly.users:10342

Simon 'corecode' Schubert wrote:
> Bill Hacker wrote:
>> CVS has been the 'compromise' that is at least not harmful or overly
>> demanding.
> 
> CVS *is* harmful.

To you, and other running experimental differences, perhaps so..

>  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.

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

As few surprises as possible.

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.

The alternatives are no longer new, nor are they without their own set 
of irritants.

>> 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.

> 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.

>> If it adds enough value to enough people, bandwidth and storage will be
>> attracted to the solution.
> 
> Bandwidth and storage isn't the issue.  I can develop forever in my git
> repo, and nobody might ever notice.  And it won't magically make the
> project switch from CVS.
> 
> cheers
>   simon

 From tracking your work, I fully appreciate that you have made a great 
deal of effort, committed a lot of time and resources, and delivered 
much valuable code - so yes = anything that removes barriers to that 
gets some support.

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.


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.

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.

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

;-)

Bill