DragonFly users List (threaded) for 2008-01
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: cvsup
> <4794968D.8080501@fs.ei.tum.de>
In-Reply-To: <4794968D.8080501@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@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
- References:
- cvsup
- From: Vincent Stemen <vs1@crel.us>
- Re: cvsup
- From: "Simon 'corecode' Schubert" <corecode@fs.ei.tum.de>
- Re: cvsup
- From: Vincent Stemen <vs1@crel.us>
- Re: cvsup
- From: "Simon 'corecode' Schubert" <corecode@fs.ei.tum.de>
- Re: cvsup
- From: Vincent Stemen <vs1@crel.us>
- Re: cvsup
- From: Bill Hacker <wbh@conducive.org>
- Re: cvsup
- From: Vincent Stemen <vs1@crel.us>
- Re: cvsup
- From: "Justin C. Sherrill" <justin@shiningsilence.com>
- Re: cvsup
- From: Matthew Dillon <dillon@apollo.backplane.com>
- Re: cvsup
- From: "Simon 'corecode' Schubert" <corecode@fs.ei.tum.de>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]