Moving xlibs modules to xorg

[Daniel Stone]

On Sun, Mar 05, 2006 at 12:08:35PM -0800, Keith Packard wrote:
> I'm starting to migrate modules which were 'canonical' in xlibs over to
> xorg. The first three of these are the newest extensions, fixes, damage
> and composite.
> 
> At this point, I have them only in git form and have exported them as
> such.

I have them in CVS form.  The whole repository.

> There is a new git-cvsserver utility which is currently under
> review (by lots of people) which would make these available via pserver
> for anonymous CVS access. 

When?

> I'd prefer to avoid pushing these patches back into CVS; I've spent too
> much time in the last week trying to figure out how to get the X server
> migrated to git after that tree was mangled as it moved from XFree86 to
> X.org. CVS is far worse than you can possibly imagine...

I fail to see how unilaterally declaring development to be moved to a
completely different revision control system fixes this in any way.
Looking at
http://gitweb.freedesktop.org/?p=xorg-lib-libX11;a=shortlog;h=f71ea0bc737c5a42e9e022b86e7ec3b4f846d31c;pg=1,
I see the first commit of any importance to be 'Merging XORG-CURRENT
into trunk', which is a neat condensation of several years of history.

Yes, CVS is braindamaged, but git hasn't made any of this historical
braindamage disappear, and you can actually route around new problems if
you're reasonably careful enough.  So, for a small win in being able to
be more careless with branching and merging, we lose the familiarity of
CVS -- I still have not seen any compelling 'this is how you manage your
normal workflow with git' tutorials[0] -- we lose CVS pserver, we end up
running a non-chrooted service that depends on the ability to invoke
random other processes, on a supposedly bulletproof secure machine, and
we end up with still more confusion between:
    * xlibs/*: the generally-accepted baseline until R7.
    * xorg/{proto,lib}/*: where development has happened, particularly
      after repeated assertions that it would become the canonical tree
      when R7 was released.
    * git: this is the place where libX11 and the three new-ish
      extensions live now, so I'm told.

I don't see why there's such a hideously urgent need to move to git.
Yes, CVS bites.  It sucks as much now as it does in 2004.  (However, I'd
be lying if I said I'd had CVS murder my trees.  Dead laptop hard
drives, yes; user stupidity, yes; CVS, no.)  Call me cynical, but I
don't see the benefits in announcing that development of a particular
module has moved here, and this is where you all must commit (including
enforcing same with permissions) unexpectedly on a list one day.

Particularly when there are significant concerns about the revision
control system being chosen, which are generally handwaved away with
'well, moving to other revision control systems is painless' (it's not),
and it's still alarmingly unclear which non-CVS system to use in future.

-d

[0]: Nor is it in any way obvious.  I haven't read any documentation on
     darcs beyond --help, but I'm already doing massively-branched
     development, keeping some branches temporarily private, pushing to
     several different repositories including a master, setting up
     automatic email-based patch submission, several other compellingly
     good features, and it's all blindingly obvious.  I've read two
     documents on git now, got bored, and just kept on maintaining
     private branches in darcs, because git's UI very closely resembles
     tla's in 2004, including the same fundamental mistakes that result
     in a hideous UI.  Even after that, I still can't tell you how to
     make a branch in git, do some development in it, and merge to
     mainline.  Ho hum.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060305/7d824cfd/attachment.pgp>