On Sat, 2007-11-10 at 10:42 -0500, Jesse Keating 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.
In that case, enjoy the list of problem areas below, i.e. where
non-distributed VCSs stand in the way. I've marked things where the
workflow would benefit with "===> ... <===" ;-).
How I see it is that the features of DVCSs are often deficiencies in
non-distributed VCSs. Using a better VCS would be worthwhile because of
the many situations where CVS stands in the way (and SVN isn't much
better):
- Slow operations, almost(?(*)) everything needs server round-trips,
just one example: for the CVS changelog I like to grep the changes in
the RPM %changelog. It usually takes a 10-20 seconds round-trip to
generate the diff of the spec file. That sucks. Same goes for tagging
though this isn't as tragic as you can chain the build after it in the
same make command. ===> I would be a good deal happier and probably more
productive if these operations were quicker <===.
(*) ok, just about everything with CVS. SVN manages to diff *against the
currently checked out revision* without a round trip. Big deal.
- Merging sucks with CVS. We currently have that byzantine setup of
not-real-branches-but-subdirectories specifically because merging with
CVS is an exercise in masochism and copying files around is much easier.
I thought that this was a mistake from the beginning, but with CVS that
wasn't obvious and when we did it there were few real alternatives.
Practically CVS is of no help for merging, the person in front of the
computer is effectively the VCS. Linus asks a good question in his
Google Techtalk speech (paraphrased): "How many of you merged branches
with CVS and enjoyed the experience?".
- I regularly do the same release for 3 Fedora versions --
Rawhide, F8, F7 nowadays -- (or more than one at least) and ===>
it'd be so much better if I could change the spec file, add one
patch, remove a second and update another just in the devel
branch, then merge that changeset over to the other Fedora
versions <===. If there are conflicts, the VCS shouldn't clutter
up my files but run a tool like meld which lets me resolve the
conflicts rather easily. And it should remember the merges, so I
can merge again in the future and keep my sanity. With CVS/SVN,
this is a no go.
- Often I get bug reports with specific patches and related
changed spec files. Again, often these changes are done against
an older revision of the spec file so I need to re-do the
changes so they match what is current. ===> If we used a DVCS,
people could just e.g. "hg bundle" up their changes they did in
their own repo, attach them to the bug or mail them to me, I
could unbundle the changeset into the repo, merge and be happy
<===.
These extra "complexities"(**) you mention, in fact the whole VCS
implementation, could easily be hidden behind "make [up|update]", "make
[commit|ci]", etc. Makefile targets.
(**): ... which I don't deem really complex. It took me about half an
hour to "master" the switch from CVS to Hg. Let me postulate that CVS
just isn't deemed as complex because we're used to it.
I know that we get by with using CVS, but I hope we're not content with
just getting by. CVS is at points so cumbersome that I think we're at a
point where we need reasons for staying with it rather than for moving
away from it. We consistently push the envelope in new technology in the
distribution, I think we should do the same in how the distribution is
built.
Mind that people mastered the "complexities" of having to deal with
bodhi as well, which was much more disruptive for someone who in the
past got by with "cvs up, <change stuff>, cvs ci, make tag build". If
they can do that, they can surely master using a DVCS, especially if
it's 90% command line compatible like Mercurial. If we don't hide the
used VCS and its complexity behind Makefile targets anyway that is.
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
