When will CVS be replaced by modern version control system?

[Les Mikesell]

Nils Philippsen wrote:

>>>> This is a different operation than having every developer have his own 
>>>> copy - or at least one in every location where development happens. The 
>>>> ability to work disconnected was being touted as a feature,  But what 
>>>> happens if a release needed to be done at the central build system and 
>>>> the work some remote developer thinks is committed has not actually made 
>>>> it there because it is still disconnected?
>>> If you're disconnected, "make build" or a not yet existent "make commit"
>>> fails. Of course you need a connection to get the build system to build
>>> a package. But you can develop things locally (make srpm, make
>>> i386, ..., test things) and e.g. easily revert changes that didn't work
>>> out because you have a VCS available, even in a plane. The hurdle to
>>> experiment with new things is much lower if you can easily get back to a
>>> working state.
>>>
>>> Being able to work disconnected (to a feasible extent) is just one
>>> feature of a distributed VCS:
>> Which still doesn't address what happens in practice when the remote 
>> repository containing changes that the central repo doing the official 
>> build needs is still disconnected - or how anyone knows about it.
> 
> That's the same if you don't commit your changes to the CVS repo before
> building.

Except that it is obvious to all concerned and you don't proceed to do 
more work on the premise that everything is OK.

> For all practical purposes regarding this discussion, you can
> equate a CVS commit with a Hg push. Without committing to the build
> repository, there is nothing from which to build. Nothing new here.

Yes, but what is the procedure to know whether it was done?

>>  Or how 
>> the much larger conflicts that would be likely with the ability to do 
>> more work off line would be handled when they do reach the repo where 
>> the build is done.
> 
> You would be notified when pushing that the push would create new
> branches in the upstream repository. Unless you were forcing the push
> (not a good idea obviously), you would merge locally, whereby you would
> be the one to resolve the conflicts. The automatic invocation of meld
> (or another 3way diff tool) helps tremendously.
> 
> If anything it would be worse with CVS: when working disconnectedly, you
> would have to resolve the conflicts, only that you would have to do so
> without the help of the VCS -- only you and your vim (or emacs, or ...)
> -- and in one go. With a DVCS, you could merge your individual changes
> step by step instead of the whole work at once which should make
> resolving conflicts much easier.

Isn't it a rare case where you'd want to try to resolve conflicts 
offline - given that you might not be working against actual current 
revisions anyway?   And online, doesn't meld work with CVS?

-- 
   Les Mikesell
    lesmikesell at gmail.com