On Sun, 2007-11-11 at 12:05 -0600, Les Mikesell wrote:
> 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. 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.
> 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.
Nils
--
Nils Philippsen / Red Hat / nphilipp@xxxxxxxxxx
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
