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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
