RFR: GIT Package VCS

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070607/81e23a71/attachment.sig>