On Sat, 10 Nov 2007 10:42:45 -0500 Jesse Keating <jkeating@xxxxxxxxxxxxxxx> wrote: > On Sat, 10 Nov 2007 14:10:38 +0100 > Nils Philippsen <nphilipp@xxxxxxxxxx> 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. I think it's because you have two classes of users. Developers, and packagers. There are several people that are active developers for the packages they maintain. They're used to working on the code base itself, developing patches, etc. RPM specfiles are almost the last step in their day-to-day dealings with a package. These are the people that are the major proponents of a DVCS. Then there are the packagers. They mostly take the upstream tarballs, do the specfile work, and build things. There isn't a lot of need for multiple commits, offline working, etc. The entire VCS setup we currently use is geared toward packagers. josh -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
