SCM choices for the server (was Re: kdrive and xgl DDXes)

Felix Kühling fxkuehl at gmx.de
Wed Jun 22 18:02:08 PDT 2005


Am Mittwoch, den 22.06.2005, 14:51 -0400 schrieb Adam Jackson:
> On Wednesday 22 June 2005 13:13, Keith Packard wrote:
> > On Wed, 2005-06-22 at 13:05 -0400, Adam Jackson wrote:
> > > Fair enough.  Are we planning to move kdrive and xgl into the same CVS
> > > module as the other DDXes at some point?
> >
> > Dunno.  It's kinda nice to have a place to play that doesn't affect any
> > distributions...
> >
> > Would be nicer if we had a 'real' SCM.
> 
> I definitely agree.  And before we go any further down that line of 
> discussion, let's formally declare what seems to be the consensus:
> 
>     kdrive and xgl will not be in 7.0.
> 
> So there.  We may want to tag and tarball that tree at some point for a 
> semi-stable release, but that's a parallel effort.
> 
> So the next question is how we want server development to look in the future, 
> and tied up in that decision is our choice of SCM.  I think if we stay with 
> CVS for the release server, then we definitely need a separate tree for 
> experimental, which means the joy of syncing.  I suspect no one wants to use 
> CVS more than necessary though.
> 
> I don't know enough about the choices to make any authoritative decision, and 
> I certainly don't expect any consensus out of this thread.  But I would like 
> to hear some ideas.
> 
> - ajax

I've been using Subversion for my own stuff for a while, and I'm quite
happy with it. The basic concept and user interface is similar to CVS,
so there is hardly any learning curve. Some nice features of subversion
include

      * atomic commits (transaction semantics)
      * time of many operations depends on the change size, not the
        repository size (for example svn update).
      * needs less network bandwidth than CVS by sending diffs in both
        directions
      * some operations can be performed off-line (svn diff against last
        checked-out revision, svn revert, svn status)
      * directory structure is under version control, moving/renaming
        files and directories while preserving the history is trivially
        easy
      * supports symbolic links
      * revision numbers are consistent across the entire repository (in
        CVS revision numbers are per-file)
      * branches are just directories in the repository. Branching a
        tree makes a "cheap" copy that shares a common history with the
        original tree
      * Subversion users are managed independently from system users.
        Thus no ssh access is required for accessing the repository.
        With the Apache module you can get fine-grained access control
        per-directory instead of per-repository (never tried that
        myself, though). In theory that allows for example limited
        access to certain branches in the repository (for example
        release branches) or giving new commiters access to a specific
        branch only

For more info see http://subversion.tigris.org.

I have no intention of starting a discussion or flame war here. Just
tossing in some facts for those who have to make a decision in the end.

Regards,
  Felix

-- 
| Felix Kühling <fxkuehl at gmx.de>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |




More information about the xorg-modular mailing list