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