On Thu, 2007-06-07 at 20:37 +0200, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 à 11:06 -0700, Toshio Kuratomi a écrit : > > > Absolutely -- they have different reasons for wanting this than we do. > > Wanting what? > > If what = kill centralised cvs for modern scm exploded trees, with > cvs/svn/whatever gateways, while keeping the current srpm export/import > modes, why not > Yes. But what is the end of your proposal? > If what = get everyone to use _insert_preferred_scm_there and kill other > access modes → not good > To be sure I understand, what are the other access modes? > > Our reasons are: > > 1) Better able to work with upstream > > Upstreams do not agree on scm choices (when they use one) > True. but: 1) If we were to share the same DRCS with upstream we would have the ability to share code with them through the DRCS whereas if we share cvs in common with upstream, we are not. 2) Having the ability to pull arbitrary patches out of our VCS vs pulling a discrete patch out of our current CVS system is a postive thing for working with upstream. I can provide upstream with new patches that are a subset of all the changes I made in a patch if they like some of what I did but not all of it. When the changes come back to me in the next release, I can merge that patch against the new upstream and use the VCS to help me see where things have been integrated, where they have not been merged, and where upstream has made other changes that conflict but don't solve the issue that the patch does. I can correct things that upstream thinks would better be done some other way and still have a history of what I changed in the context of the whole project. I can pull snapshots from upstream into my local repository, merge my changes from Fedora, and send the changes back to upstream against their current tree instead of the last released tree. If upstream is slow to respond and needs the changes ported to a new snapshot, I can use the VCS to help me merge my changes to the previous snapshot to the new one. If I need to make changes to a patchset that touches files that subsequent patchset also changes, the VCS helps me operate on the correct files at the correct time in their history and assign the changes to the correct patchset. It then helps me resolve any conflicts with the later patchset. This helps me update patches and resubmit to upstream without mingling the two separate changes. A VCS is not just a place to store changes. It is a tool to help develop and evolve changes. And that has great bearing on its ability to help interact with upstream. > > 2) Better able to rebase our local changes. > > We don't want to get good at local changes, we want to push changes > upstream, and even cvs is good enough for our basic rebasing needs today > We do want to be good at making local changes. We want to be so good at it that when we submit the changes to upstream, upstream has no trouble recognizing that they're good changes and has no issues with accepting them. Part of doing that is making sure that we keep distro-specific changes (ex: changes to the configuration files), backports, and patches sent upstream separate from each other. That way we can easily submit changes to upstream that are relevant to them and enjoy the benefits of version control for our changes that A) are not relevant to upstream or B) only exist in upstream's development branch. Also, cvs is not good enough for our basic needs. I always use quilt to help manage the changes that I'm making to the vanilla upstream source because cvs is not good enough. It doesn't have any facilities for seeing what order a set of patches should be applied in. It doesn't have any facilities for helping me make changes to a patch that's in the middle of a stack of logically separate changes. Even quilt can't help me when I have to update a patch with a better solution. cvs diff -r 1 -r 2 apatchfile.patch is less than ideal. > > 3) Better able to see how our changes have been modified over time. > > See 2. > > IMHO the killer argument for SCM changes is the unconnected mode new > scms offer, but any package that needs something else than CVS because > of your 1 2 3 is in deep trouble. Disconnected mode is a killer argument for changing from cvs-dist to DRCS-dist. It doesn't address the reasons that exploded trees are good. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
