When will CVS be replaced by modern version control system?
Les Mikesell
lesmikesell at gmail.com
Sun Nov 11 20:18:55 UTC 2007
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
More information about the devel
mailing list