Jesse Keating wrote:
a) quick operations by avoiding round-trips to a remote server if
not necessary
b) easy branching and merging
c) atomic operations
d) co-maintainers (or maintainer apprentices) wouldn't need commit
access to the main repository
e) ability to do embargoed stuff like security fixes before they're
public
f) ability to rename things, especially handy for re-worked patches in
our context
I don't disagree that those things are nice with DVCS. What I question
is the amount of times they're necessary to warrant the extra
complexity of a DVCS thrown at every user.
And still I continue to hear just features of dvcs, but not applied to
a workflow for our Package vcs.
And in particular, they don't describe how that workflow ensures that
the central build system knows that all distributed operations are
synchronized and what happens if they aren't. I assume that's a solved
problem with these systems since they don't make much sense otherwise,
but...
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
